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ABSTRACT 


This  thesis  focuses  on  the  development  of  a  data-driven 
decision  support  system  to  assist  the  Egyptian  procurement 
activities  in  foreign  countries.  The  Egyptian  Procurement 
Office  in  Washington  D.C.  (POW)  is  taken  as  an  example  to 
apply  this  research.  Two  areas  of  procurement  type  have  been 
examined  in  POW,  the  Commercial  Procurement  and  the  Govern- 
ment Procurement  activities,  the  later  type  is  based  on  the 
USA  Foreign  Military  Sales  ( FMS ) , s y stem .  The  Data  Flow  Diag- 
ram -technique  have  been  used  to  analyze  the  system.  PC/FOCUS 
have  been  used  to  design  a  prototype  software  for  the  POV/ 
Commercial  Procurement  subsystem  to  use  in  an  IBM -XT  or  13 M- 
AT  or  compatible  microcomputers. 
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I .  INTRODUCTION 

A.  OBJECTIVES  OF  THESIS 

The  objectives  of  this  thesis  are  to  analyze  the  current 
procurement  system  of  the  Egyptian  Procurement  Office  in 
Washington  D.C.  (POW)  to  determine: 

1.  Decision  criteria  are  used  to  select  vendors  to 
receive  the  RF  P ' s ; 

2.  The  most  effective  way  to  monitor  and  administer 
the  contracts; 

3.  The  best  way  to  accelerate  LOA ' s  process  and 
provide  the  required  information  in  the  shortest 
time  possible; 

4.  The  design  of  a  prototype  decision  support 
database  system  using  PC/FOCUS  DBMS  on  an  IBM  XT  or 
AT  computer  to  replace  the  current  manual  POW 
system . 

The   development   of  such  a  system  creates  a  valuable  DSS 

tool,   the   database,   to  support  the  POW.  This  system  may  be 

considered   as   a  DSS  generator  for  developing  a  specific  DSS 

to   include   all  functions  of  POW  after  getting  feedback  from 

users  . 

B.  BACKGROUND 

The  strategic  policy  of  the  Egyptian  Government  since 
1973  has  been  to  procure  weapons  systems  and  military  equip- 
ment from  different  countries  in  order  to  modernize  the 
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Egyptian  Armed  Forces.  The  Egyptian  Armament  Authority  ( AA ) 
is  responsible  for  the  procurement  activities  from  foreign 
countries.  To  effectively  accomplish  its  job,  it  has  front 
offices  in  those  countries,  called  Procurement  Offices  (PO). 
The  Procurement  Office  in  V/ashington  (POW)  is  one  of  these 
offices.  The  POW  deals  with  two  kinds  of  procurements, 
commercial  procurement  of  the  military  items  from  the  open 
market  inside  the  USA,  and  government  procurement  from  the 
Government  of  the  USA.  The  POW  functions  are  summarized 
below. 

The  following  are  the  POW  functions  outlines.. 

"1  .   Commercial  Procurement 

The  POW  does  the  following  important  functios:  (1) 
receives  Requests  For  Proposals  (RFP's)  coming  from  AA,  (2) 
prepares  vendor  list  of  the  eligible  and  suitable  vendors  to 
receive  the  RFP's,  (3)  calls  vendors  for  bids,  (4)  receives 
and  verifies  proposals  from  vendors  and  forwards  them  to  A A 
(5)  Monitors  and  administers  the  active  contracts  inside  the 
USA. 

2 .   Government  Procurement 

All  the  requests  for  purchasing  weapons  from  the  USA 
Government  must  be  submitted  on  a  special  form  called 
_Request  of  Offer  and  Acceptance;  (RO_A).  After  many  procedur- 
es in  the  USA  administration  the  accepted  ROA  becomes  a 
Letter  of  Offer  and  Acceptance  (LOA)  which  is  a  contract 
between   the   United   States   of  America  and  Egypt.  The  LOA's 
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are  prepared  in  Egypt  by  the  AA  and  the  specialized  depart- 
ments according  to  our  -needs  and  the  weapons  acquisition 
plan.  The  POW  responsibilities  in  this  kind  of  procure  (nent 
are:  (1)  receive  all  the  ROA's  coming  from  AA  and  forwards 
them  to  the  USA  Security  and  Assistance  Center  (USASAC), 
"which  is  responsible  for  Foreign  Military  Sales  to  alien 
and  friendly  countries",  (2)  keep  track  of  all  ROA's  status 
sent  to  USA-SAC  until  final  acceptance  as  an  LOA,  and  (3) 
receive  and  process  requisitions  for  Purchasing  spare  parts 
needed  for  the  weapons  already  purchased  from  the  USA  and  in 
the  service  of  Egyptian  Armed  Forces. 


C.   PROBLEMS  TO  BE  SOLVED 

Due  to  the  continued  growth  of  the  numbers  of  RFP's, 
open  contracts,  and  LOA ' s ,  the  current  manual  system  needed 
to  be  improved  to  allow  better  performance  of  the  procure- 
ment process.  The  following  are  the  major  problems  with  the 
currentPOWsystem. 

1 .   RFP's  Function 

This  process  requires  a  great  deal  of  effort  to 
effectively  decide  who  are  the  suitable  vendors  to  receive  a 
particular  RFP.  A  pre-selected  criterion  must  be  applied  for 
each  vendor.  The  growing  numbers  of  RFP's  coming  from 
Egypt,  the  large  numbers  of  vendors  available  in  USA, 
and  binding  time  constraints  are  all  important  factors  that 
may  be  causing  a  delay  in  this  process. 
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2 .  Monitor  Open  Contracts 

A  large  number  of  contracts  must  be  monitored  for 
payment,  shipment,  and  training  of  personnel.  Invoices  need 
to  be  verified  and  payed  to  prevent  problems  of  missed  or 
double  payments  of  some  invoices.  Different  kinds  of  payment 
and  fund  sources  must  be  monitored  too.  The  present  manual 
system  requires  significant  effort  to  effectively  deal  with 
these  activities. (About  100  man  hours  per  working  day  are 
needed  to  do  these  activities). 

3 .  LOA 's  Functions 

The  USA  Foreign  Military  Sales  (FMS)  procedures  are 
very"  conservative  and  lengthy.  The  POW  acts  as  a  co- 
ordinator between  the  AA  and  the  USASAC.  The  POW  is 
responsible  for  keeping  track  of  the  status  of  each  LOA 
submitted  to  USASAC.  This  process  takes  a  long  time  to  be 
completed  (at  least  two  months).  Speeding  up  this  process 
requires  a  good  monitoring  system  to  keep  track  of  the  LOA's 
and  provide  information  to  both  sides  in  the  shortest  time 
possible. 


D.    SCOPE,  LIMITATIONS,  AND  METHODOLOGY 

This  thesis  concentrates  on  the  first  two  phases  of  the 
DSS  development  life-cycle  ,  ie.  systems  analysis  followed 
by  the  design  of  a  prototype  database  for  the  commercial 
procurement  activities  of  POW.  The  software  utilities  of 
PC/FOCUS   DBMS   will   be   used   to  develop  the  prototype.  The 
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result   of   this   research   may   be   easily   adapted   to   any 
similar  office  in  other  f orei gn  .  coun t r i es . 

In  the  analysis  phase,  Structured  Systems  ^Analysis  (S3A) 
techniques  are  used  to  analyze  the  POW  system.  In  the  design 
phase,  software  engineering  methodology  is  used  to  design  a 
DSS  generator  for  the  commercial  procurement  function. 
Through  the  analysis  and  design  phases,  the  DSS  approach  is 
used.  In  Appendix  A,  we  present  an  overview  about  the  Data 
Flow  Diagram  conventions. 

E.   ORGANIZATION  OF  THE  THESIS 

The  thesis  is  structured  as  follows:  Chapter  II 
describes  the  POW  current  system.  Chapter  III  describes  the 
detailed  problems  and  opportunities  of  the  current  POW 
system.  Chapter  IV  discusses  the  software  requirement 
specifications  of  POW.  Chapter  V  provides  the  software 
design  to  build  the  DSS  generator,  the  database  system  for 
the  POW  Commercial  Procurement  System  (POWCP).  Chapter  VI 
presents  the  conclusions  and  recommendations  of  the  thesis. 
Appendix  A  discusses  the  Data  Flow  Diagram  conventions. 
Appendix  B  provides  the  software  module  listings.  Appendix  C 
provides  the  data  dictionary  of  the  existing  system. 
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II.  THE  CURRENT  POW  SYSTEM 

A.   INTRODUCTION 

This  chapter  describes  in  detail  the  current  POW  inform- 
ation flow  structure.  The  approach  taken  for  this 
information  analysis  is  to  adopt  the  Data  Flow  Diagram 
techniques  proposed  by  Gane  and  Sarson  [Ref.  jj.  A 
comprehensive  discussion  of  this  technique  is  given  in 
Appendix  A. 

The  POW  is  the  most  important  procurement  office  outside 
Egypt,  because  of  the  heavy  demands  of  the  AA  and  the 
specialized  departments  to  procure  weapons  and  military 
items  from  the  USA.  The  primary  goal  of  POW  is  to  provide 
procurement  functions  from  the  USA  in  the  most  efficient  and 
effective  ways.  Officers  from  different  major  forces  and 
specialized  departments  are  selected  to  work  in  this  office 
to  deal  with  the  variety  of  weapons  and  military  items 
required  by  Egyptian  Armed  Forces. 

The  rest  of  this  chapter  describes  the  organization  and 
the  major  functios  of  the  POW  in  both  commercial  and 
government  procurement.  Data  Flow  Diagram  techniques  are 
used  to  picture  the  system,  the  Data  Dictionary  is  used  to 
document  the  system. 
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B.   POW  ORGANIZATION 

POW  consists  of  the  POW  Director,  POW  Director  Assistant 
Officers  or  the  Specialized  Officers  (SO's),  Contracting 
Officer  (CO),  Financial  Officer  (FO),  Shipment  Officer 
(SHO),  and  Administrative  Officers  (AO), (These  abbreviations 
will  be  used  in  the  DFD  and  data  dictionary.).  All  officers 
are  selected  from  different  Forces  of  Egyptian  Armed  Forces 
(EGAF)  to  represent  the  major  specializations  in  EGAF. 

1 .  Organization  Chart 

Figure  2.1  shows  the  organization  of  POW.  As  we  can 
see,  the  POW  Director  has  the  overall  responsibility'  for  the 
procurement  functions  inside  the  USA.  The  other  officers 
a-ssist  him  in  doing  his  job.  The  organization  consists  of 
sections.  Five  specialized  sections  represent  the  major 
topic  areas  of  Egyptian  Armed  Forces,  each  one  is  headed  by 
a  specialized  officer  in  the  particular  area.  The  Administr- 
ation and  Control  section  headed  by  a  qualified  officer  in 
administration.  The  Financial  and  Accounting  section  headed 
by  an  officer  from  the  Financial  Affairs  Authority.  The 
Shipment  section  headed  by  a  qualified  officer  which  is 
responsible  for  monitoring  shipment  of  contract  items  to 
Egypt  . 

2 .  The  POW  Procurement  Responsibilities  in  USA; 

a.  Apply   and   follow   the   Egyptian  defence  procurement 
laws  and  regulations. 

b.  Implement  the  procurement  plan  of  AA. 
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c.  Use  funds  available  in  the  most  effective  and 
flexible  way. 

d.  Assure  appropriate  contract  type. 

e.  Reduce  the  procurement  cost  and  shorten  the 
procurement  period. 

f.  Improve  vendor  selection  function  and  keep  an 
up-todate  information  about  vendors. 

g.  Increase  competition  between  vendors. 

h.  Develop  and  use  standard  operation  and  support 
systems  to  perform  the  procurement  function 
effectively. 

i.  Monitor  shipment  of  the  contract  items  to  the 
country. 

j.  Monitor  training  of  personnel  associated  with  the 
contracts. 

The   POW  director  is  responsible  for  proper  execution 

of   all  the  above  functions.  Figure  2.2  shows  all  AA  requests 

from    POW   and   Figure   2. J   shows   POW   relationships   with 

external  agencies. 

3 .   Job  Responsibility  of  the  Specialized  Of f icer s ( SO ) : 

a.  Apply  all  the  procurement  functions  as  stated  in 
I t em  2 . 

b.  Follow  the  orders  and  directives  of  the  POW 
Director. 

c.  Check  the  RFP's  received  from  AA  for  proper 
specifications  and  style  before  forwarding  to 
vendors  . 

d.  Apply  vendor  selection  rules  and  criteria  to 
achieve  full  and  open  competition  between  vendors. 

e.  Maintain  fairness  and  equal  opportunity  among  all 
vendors  by  providing  them  with  all  information 
•concerning  a  particular  RFP. 

f.  Receive  and  verify  proposals  for  completeness 
before  sending  them  back  to  AA. 
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g.  Check  all  received  payment  documents  from  vendors 
and  approve  them  for  payment. 

4 .   Job  Responsibilities  of  the  Contracting  Officer : 

a.  Apply  Egyptian  defence  legislation  and  directives 
related  to  the  procurement  process. 

b.  Check  all  contract  terms  for  correctness  and 
completeness  before  signing  by  POW  Director. 

c.  Check  and  review  vendor  financial  status  before 
putting  them  in  the  vendor  list. 

d.  Keep  track  of  all  open  contracts  and  monitor 
vendor  performance  in  contract  implementation. 

e.  Prepare  a  termination  notice,  if  necessary,  for 
inactive  vendors. 

f_.  Deal  with  all  problems  and  complaints  from 
vendors. 

g.  Participate  in  the  procurement  committees  in  POW 
and  check  that  all  vendors  are  qualified  to  attend  a 
committee  and  have  all  the  necessary  certificates 
and  warranty  letters. 

The    following   sections   describe   the   POW   system 

functions.    Two    types    of   procurements   are   exist,   the 

commercial  procurement  and  the  government  procurement. 


C.   COMMERCIAL  PROCUREMENT  FUNCTION 

The   commercial  procurement  function  is  divided  into  five 
processes,  as  shown  in  the  DFD  in  Figure  2.4. 

1 .  RFP  '  3  Function 

2 .  RFC  '  s  Funct  ion 

3.  Fund  contracts. 

4.  Administer  contracts 

5.  Generate  Vendor  list 
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Each  one  of  the  above  processes  is  expanded  into 
several  other  processes  in  a  top  down  fashion  to  show  more 
details.  In  each  level  of  details,  a  walkthrough  is  present- 
ed to  explain  each  process  associated  with  the  DFD.  In  the 
data  dictionary,  a  detailed  description  of  the  processes  is 
presented. 

1  .   RFP's  Function 

The  RFP  is  the  official  communication  from  the 
Government  of  Egypt  to  the  market.  For  easy  explanation,  we 
take  a  particular  RFP  and  follow  its  sequence.  Figure  2.5 
illustrates  this  process  as  a  DFD.  The  process  starts  when 
a  particular  Force  or  Department  of  EGAF's  "requester"  asks 
the  Ministry  of  Defense  (MoD)  for  funding  for  certain  kinds 
of  military  items  from  the  USA.  After  receiving  a  fund 
letter  from  MoD,  a  Committee  is  designated  to  prepare  the 
RFP.  The  objective  of  the  RFP  is  to  provide  prospective 
vendors  with  adequate  information  and  guidance,  presented  in 
a  clear  and  logical  manner.  Basically,  preparation  of  the 
RFP  is  a  team  effort. 

a.   Receive  RFP  by  AA 

After  final  approval  of  the  RFP,  the  requester 
sends  it  to  AA.  Any  particular  RFP  usually  contains  the 
following  information: 

(  1  )   Terms 

(2)   Evaluation  factors 

(  3  )   Spec  ification 
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(4)  Delivery  schedule 

(5)  Quality  assurance 

b.  Check  RFP  in  AA 

The  RFP  is  checked  against  the  annual 
procurement  plan  of  the  requester.  The  RFP  must  be  clear, 
complete,  and  consistent  with  the  requirement  of  procurement 
so  that  it  provides  all  vendors  with  the  same  understanding. 
After  checking,  the  AA  sends  the  RFP  to  POW. 

c.  Check  RFP  in  POW 

Once  received  by  the  POW,  the  RFP  is  registered 
in  the  General  Log  Book  by  the  Admins ter at i ve  section,  and 
then  routed  to  the  Specialized  Officer  in  the  area,  who 
reviews  the  RFP  to  be  sure  that  the  specifications  are  clear 
and  complete  and  items  are  clearly  identified.  (Figure  2.6) 

d.  Select  Vendors 

The  SO  selects  vendors  who  will  receive  the  RFP 
from  the  vendor  lists  available  in  POW,  or  by  using  a 
special  catalog  called  the  Thomas  Register  which  contains 
most  of  vendors  in  the  USA.  He  prepares  a  list  of  the 
vendors  matched  with  the  RFP  item  specifications  and 
approves  it  with  the  POW  Director. 

e .  Issue  RFP 

The  necessary  number  of  copies  of  the  RFP  is 
prepared  and  mailed  to  the  selected  vendors.  First  time 
vendors   must   fillout   a   special   Qualification   Form.   The 
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letter  sent  to  the  vendors  clarifies  all  the  general  terms 
and  conditions  that  must  be  followed  by  the  vendors  as  well 
as  the  closing  date  for  receiving  the  proposals.  Sometimes, 
for  important  RFP's,  a  pre-proposal  conference  may  be 
scheduled  to  allow  vendors  to  clarify  sections  of  the  RFP 
they  may  not  fully  understand. 

f.   Check  Incomming  Proposals 

SO   checks   and   reviews   all  incoming  proposals. 
Only   relevant   and  complete  proposals  from  qualified  vendors 
are  sent  to  Egypt.  (Figure  2.7) 
2.   RFC ' s  Function 

Sometimes,  AA  authorizes  POW  to  contract  with  vend- 
ors. It  sends  a  Request  For  Contracting  (RFC)  to  POW.  The 
RFC  must  contains  all  the  necessary  documents  for  doing  the 
contract  process.  Two  kinds  of  requests  may  be  received,  RFC 
with  a  specific  vendor  already  selected  by  AA  or  a  list  of 
technically  accepted  vendors  to  choose  from.  The  awards  are 
generally  based  on  cost.  If  two  vendors  have  similar  cost 
bids,  previous  contracts  with  Egypt  or  the  USA  Armed  Forces 
are  considered.  The  following  are  the  procedures  for  a 
particular  RFC:  (Figure  2.8) 

a.   The  Specialized  Officer  (SO) 

Receive  and  review  the  RFC  in  the  area.  The  most 
important  document  received  with  the  RFC  is  the  technical 
evaluation  and  accepfance  of  vendors  and  the  best  and  final 
offers  of  each  vendor. 

29 


VENDOR. 


Pifoposais 

► 


D2 


VENDORS 


1.2  Receive  Proposals 


r 


1.2.1 


Register  the 
proposals  in 
Gen.  Book 


AO 


•~\ 


Dale  Received 


D7 


GENERAL  L06  BOOK 


Proposals 


3L 


Prop. 


lo  AA 


1.2.3 


Prepare 
Summary  I  Prop. 
Report        )^ — ^ 


V 


SO 

1 — 


''  1. 

2.2          ! 

Scan    Prop, 
for  comp. 
and  validitv 

I 

\ 

SO            ! 

Prop. 
Summary 
Data  t 


D6 


■L     Proposals 


PENDING  PROPOSALS 


Vendor  names 


RFP  nonilor  File 


Qualification 


Form  For  New  Vendors 


1  .1.4 


Check 

vendor 

Validity 


SO 

-It 


J 


Vendor 
Data 


Dl 


VENDOR  LIST 


POW 


FILE 


Figure  2.7    Receive  Proposals 


30 


Contracts 


■^ 


2.  RFC  Function 


iDli     VENDOR  LIST  FILE 


I 


AdressSt 
Telphone 


r 


2.1 


Request  for  meeting 


RFC'3   ]     Process 

«^    the 

RFC's 


SO 

1 


Date  8t  fime 


I [ 

i D  1  01  Vendor  neqo.  calender 

I  ! 2 

New 


RFC 


Dg     Pending  RFC's 


X 


meeting 


2.2 


Offer 


Nego.  I 
\  Final  fli   Vendors        f**     ^  . 
■FiiF^  jVendct- 
i  Reply 


TEAM 


) 


VENDOR 


^  All  Documertf.s 


Dl  I  ALL  DOC.  FILE 


T 


2.3 


Contract 

Award 

Process 


TEAM 


4^und  Source 
Data 


CONTRACT  MONITOR  FILE         D12    FUND  SOURCE  FILE 


POW  Commitee 


Figure  2.8    RFC's  Function 


31 


b.  The  Financial  Officer  (FO) 

Checks  availability  of  funds  for  RFC. 

c.  The  Administrative  Officer  ( AO ) 

Prepares  the  Contracting  Implementation  Plan 
(CIP)  and  the  meeting  schedule  with  vendor(s).  The  AO 
informs  vendors  of  the  date  and  time  of  the  negotiation 
meeting.  The  negotiation  period  should  not  exceed  two 
weeks  . 

d.  Vendors  Negotiation 

The  POW  Director  designates  a  team  for 
discussions  and  negotiation  with  vendors.  The  team  consists 
of  members  from  specialized  officers,  the  contracting 
officer,  and  the  financial  officer.  The  negotiation  issues 
are  straightforward  and  consist  generally  of  insuring 
competition  between  vendors  and  obtaining  the  best  price  and 
conditions  possible. 

e.  Pre-Award  Survey 

This  servey  must  be  undertaken  by  the  team.  The 
factors  to  be  considered  for  each  vendor  are: 

(1)  adequate  financing, 

(2)  ability  to  meet  delivery  and  specifications, 

(3)  satisfactory  record  of  performance, 

(4)  satisfactory  record  of  integrity, 

(5)  necessary  organization,  and 

(6)  necessary  facilities  and  equipment. 
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The  contract  is  awarded  to  a  vendor  after  analysis 
and  calculation  of  all  the  above  factors.  Figure  2.9  shows 
the  RFC  process  and  Figur  2.10  shows  the  contract  award 
process . 

f.   Team  member  responsibilities  in  RFC  Process 

CI)   Contracting Officer .  Prepares   the    contract 

draft   paying   special   attention   to   the  contract  terms  and 
conditions. 

(2)  Financial  Officer.  Calculates  the  amount  of 
dollars  needed  to  fund  the  contract  and  the  initial 
deposits.  He  also  prepare  the  payment. 

(3)  Specialized  Officer.  Checks  all  thetechnical 
terms  of  the  contract  e.g.  item  catalog  numbers,  warranty 
period, inspection   plan, technical   assistance, training   plan. 

(4)  Administrative  Officer.  Collects  and  keeps  all 
documents  of  the  RFC  and  records  all  events  in  a  special  Log 
Boo  k .       .        ■ 

(5)  POW  Pi  rector  .  Checks  and  approves  the  contract 
before  the  final  signature,  and  then  invite  the  selected 
vendor  to  sign  the  contract  in  POW. 

All  the  contract  related  documents  are  collected  in 
a  file  until  the  implementation  phase.  A  contract  monitor 
record  is  created  to  keep  all  active  information  about  the 
contract . 


35 


Figure  2. 1  1     Funding  the  Contracts 
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3 .   Fund  the  Contracts 

Two  types  of  fund  source  are  available:  budget  and 
loans.  Figure  2.11  shows  the  main  process  of  funding 
contracts.  Processing  of  any  procurement  activities  cannot 
be  started  unless  POW  receives  the  financial  letter  that 
assigns  the  money  value  and  the  source  of  funds  to  be  used. 
The  preparation  of  defense  budget  and  loans  is  beyond  the 
scope  of  POW  functions.  The  POW  responsibility  is  to 
effectively  manage  funds  dedicated  to  new  or  currently 
active  contracts.  The  cash  needed  over  a  period  of  time  must 
be  carefully  calculated.  Monitoring  the  cash  flow  and  bank 
status  is  one  of  POW's  major  functions.  The  following  are 
the  procedure  to  fund  the  contracts. 

a.   Funding  from  Budget 

( 1 )  The  Needed  Documents  are  (Figure  2.12); 

FUNDING  LETTER  —  Received  from  AA. 

LETTER    OF    CREDIT  —  Received    from    the    Central 
National   Bank   of   Egypt   (CNBOEG)   amounting  to  the 
total  value  of   contract  and   the   advance   deposit 
to  be  paid  to  the  vendor. 

LETTER  OF  GUARANTEE  —  Received  from  vendor  for 
the  security  of  contract  execution  from  vendor. 

LETTER  OF  GUARANTEE  —  Received  from  vendor  for 
the  amount  of  advance  deposit  he  receives  after 
signing  the  contract. 

OTHER  DOCUMENTS  AND  CERTIFICATES — These  documents 
are  related  to  the  contract  e.g.  warranty,  inspec- 
tion, source  manufacture  certificate  etc. 

(2)  Open   Letter   of   Credit.  Send  letter  to  the 
specified   bank   to   open   in  favor  of  the  vendor  a  confirmed 
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and  irrecoverable  letter  of  credit,  in  .a  prepared  form 
letter . 

(3)    Activate   the   Contract.   The   contract   is 
activated  and  implemented  upon  the  agreement  date. 
b.   Funding  from  Loans 

(1)  Determine   the   Source   of  Fund.  The  initial 
funding  letter  with  the  RFP  determines  the  source  of  funds 
and   whether  or  not  it's  funded  from  USA  loans.  POW  considers 
that  when  preparing  the  vendor  list  for  the  RFP. 

(2)  Use   the Loans .    The  loans   are   already 

approved  and  available  for  withdrawal.  One  loan  may  serve 
many  contracts.  Loan-based  procurements  are  constrained  by 
many  factors  such  as:  vendor  selection,  manufacture  product, 
and  limited  amount  of  dollars.  AA  understands  these 
constraints  and  follows  its  rules  accordingly. 

( 3 )  Process  Funding  from  Loans .  After  finish- 
ing the  contracting  phase,  POW  sends  a  letter  to  the  Defense 
Security  and  Assistance  Agency  (DSAA)  asking  them  for 
funding  the  contract  from  a  loan,  (Figure  2.13  )  shows  the 
procedures  of  loan  funding.  Two  documents  must  be  supplied 
with  this  letter:  a  copy  from  the  signed  contract  and  the 
Justification   Sheet   which  is  prepared  by  DSAA  to 

assist  the  procurement.  The  request  is  processed  by  DSAA 
and,  if  accepted,  a  letter  is  sent  with  the  Case  Designator 
number  for  the  contract,  which  serves  like  the  credit  letter 
from   NBOEG   in   the  budget  base  procurement.  POW  informs  the 
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vendor  by  that  number  to  start  the'  implementation  phase  of 
the  contract. 

4 .   Administer  Open  Contracts 

Each  specialized  officer  is  responsible  for 
monitoring  a  group  of  contracts  in  his  area.  The  contracts 
are  divided  into  groups  according  to  specialized  areas.  The 
major  functions  of  contract  administrations  are  shown  in 
Figure  2.14.  The  following  are  the  description  of  each 
function . 

a.   Payment 

Much   effort   and   time   are   needed   to   do  this 
function.  The  following  are  the  payment  procedures  as 
presented  in  Figure  2.15^ 

(  1  )     Receive the    Payment    Document.    POV/ 

receives  the  payment  documents  from  vendors  which 
include:  The  original  invoice,  the  original  receipt  from 
Freight  Forwarder  (FF),  who  is  responsible  for  shipment  of 
items  related  to  contracts,  and  the  original  certificate  of 
origin  for  the  items. 

(2)  Regi  ster the    Payment    Document.    All 

incoming  documents  must  be  register  in  the  central  register 
book  and  routed  to  the  responsible  specialized  officer  (SO). 

(3)  Checks  the  Payment  Document  by  SO.  The  30 
checks  the  document  with  the  contract  monitor  file  to  ensure 
that   all   the     documents   are   original   and   correct.   He 
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compares  the  invoice  with  the  shipment  notice  from  FF  to  see 
that  they  match.  He  checks  the  previous  payment  documents  to 
make  sure  there  is  no  duplication.  He  then  approves  the 
payment  from  the  technical  point  of  view  and  routes  the 
payment  documents  to  the  Financial  Officer  (FO). 

(4)  Check  the  Documents  by  FO.  The  FO  checks 
the  invoice  amount,  the  source  of  funds,  the  previous 
payments,  and  the  approval  of  the  SO.  He  prepares  the  check 
or  the  money  order  and  approves  the  payment  from  the  POW 
Director . 

b.  Monitor  Personnel  Training 

Figure  2.16  shows  the  training  procedures.  The 
training  may  be  done  in  Egypt  or  in  vendor  training  center 
in  USA.  In'  the  first  case,  the  vendor  must  inform  the  POW  at 
least  two  months  before  the  training  date  of  the  names  of 
expertise  who  will  train  our  personnel.  A  special  enquiry 
form  is  sent  to  the  vendor  to  supply  this  expertise 
information.  The  second  case,  when  training  must  be  done  in 
USA,  vendor  must  inform  POW  six  month  before  the  training 
date  of  the  date,  duration,  and  locations  of  the  training 
center,  and  the  number  of  personnel  who  will  train. 

c.  Monitor  Shipment  of  Items  to  the  Country 

A  Freight  Forwarder  (FF)  company  is  contracted 
to  do  the  shipment  of  all  items  related  to  contracts.  This 
company   is  responsible  for  safe  and  timely  transportation  of 
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contracts  items  to  Egypt.  It  keeps  all  the  documents  and 
information  related  to  the  contents  of  packages  delivered 
from  all  vendors  to  the  front  door  of  the  FF  company.  Figure 
2.17  shows  the  shipment  main  functions.  The  shipment  officer 
sets  the  priority  of  shipment  to  the  country  according  to  AA 
demands  and  informs  FF  to  take  the  necessary  actions.  The 
normal  shipment  is  done  by  the  FF.  The  shipment  officer 
receives  a  weekly  progress  report  from  FF.  This  report 
contains  the  quantity  shipped  during  the  week  and  the 
inventory  level  inside  the  FF  store  and  any  problems  to  be 
solved.  FF  receives  the  delivered  items  from  the  vendor  and 
signs  a  receipt  to  the  vendor.  This  receipt  must  be  included 
with  the  payment  document  when  delivered  to  POW. 

POW   is  equipped  by  a  computer  terminal  connected 
to   the   FF   computer   center  to  access  the  information  about 
the  shipping  status  and  the  inventory  level. 
d.   Reporting 

In  general,  the  POW  is  the  information  link 
between  AA  and  USA  government  and  market.  Good  communication 
between  POW  and  AA  is  essential  to  properly  accomplish  the 
procurement  function.  Reports  can  be  classified  under  the 
following  kinds  of  categories  (Figure  2.18):  status 
reports,  analysis  reports,  progress  reports  ,  comparison 
reports,  evaluation  reports  ,  technical  reports,  market 
research  report,  etc.  In  the  next  chapter  we  present  details 
of  all  reports  used  and  needed  by  POW. 
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5 .   Generate  Vendor  List 

The   procurement  function  in  the  USA  must  be  based  on 

competition    between   vendors.   The   Manual   of   Acquisition 

Topics  in  the  Navy  Acquisitions   [Ref.  5],  states: 

Competition  received  widespread  attention  during  1984. 
President  Reagan  stated  that  competition  "is  the  single 
most  important  source  of  innovation,  efficiency  and 
growth  in  our  economy. 

Rear  Admiral  Giordano,  SC.USN,   Chief  of  the  Supply 

Corps,  further  stated  that:    [Ref.  5] 

Competition   makes-  good   business   sense,   and  1  want  to 

make   it   clear   that   increasing   competition  must  be  a 

primary  objective  of  all  personnel  involved  in  logistics 
m'anagement . 

Commodore  Stuart  F.  Piatt,   SC,   USN ,   as  the  first 

Competition  Advocate  General  (CAG)  of  the  Navy.  He  stated: 

Competitive  procurement  represents  the  extension  of  the 
principle  of  fairness  into  the  defense  acquisition 
process.  The  public  trust  placed  in  those  who  obligate 
public  funds  includes  the  assurance  that  a  fair 
opportunity  will  be  provided  to  all  who  can  meet  Lhe 
government's  needs.  One  effective  way  to  si  ^.n  i  f  i  can  tl  y 
reduce  costs,  and  thereby  be  able  to  afford  our  defense 
requirements,  is  to  increase  the  use  of  competition. 
The  navy  is  now  emphasizing  competitive  procurement 
strongly. 

POW   should  apply  the  competitive  procurement  as  well 

Figure   2.19   shows   the  Vendor  List  source  schema  and  Figure 

2.20   shows  the  main  processes  of  generating  the  Vendor  List. 

Building   and   maintain   a   good   database   about   vendors  is 

essential.    We  call  it  the  vendor  list  in  the  manual  system. 

Bad   selection   of   vendors   may   seriously   affect  our  Armed 
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Forces.  A  number  of  different  factors  can  be  measured  to 
provide  a  basis  for  evaluating  vendors.  However,  depending 
on  the  type  of  military  items  to  be  purchased  and  the  past 
experience,  factors  may  vary  in  their  degree  of  importance. 

Any  new  vendor  to  POW  must  pass  through  extensive 
investigation  to  be  sure  that  they  have  the  qualifications 
to  be  included  in  our  vendor  list.  Figure  2.21  shows  the 
procedures  of  evaluating  new  vendors.  The  following  factors 
are  taken  into  consideration  when  evaluating  vendors: 
(Figure  2.21) 

-  Business  Assets  Value  (BAV) 
Business  Start  Date    (BSD) 

-  Source  Manufacturer,   Distributor,   or  Broker 

-  Quality 

-  Supplier  to  USA  Army/ Nav y/ Air  Force 

-  Level  of  Satisfaction  of  Previous  Contracts 
Business  Activity       CBA) 

After  recording  the  above  information  in  a 
Qualification  Form,  POW  validates  this  information  by 
asking  a  market  research  and  consumer  association  to  assess 
the  financial  capability  of  the  vendor.  This  validation  is 
always  done  for  a  new  vendor  or  in  Pre-Award  Surveys.  The 
following  are  some  quantitative  and  qualitative  Figures  that 
should  be  considered  to  review  vendor  status. 
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a.  Quantitative  Items 
Trends  in : 

-  Gross  margin  ratio 

-  Sales 
Debt/equity  ratio 
Return  on  investment 
Cash  flow/debt 

-  Working  capital  needs 
Current  ratio 

-  account  rece i v able / payable  turnover 

-  Inventory  turnover 

b.  Qualitative  Items: 

-  Credit  ratings 

-  Notes  to  financial'  statements 

-  Market  share 

Capital  asset  stability 

The  type  of  evaluation  required  to  determine  vendor 
capability  varies  with  the  nature,  complexity,  and  dollar 
value  of  the  purchase  to  be  made. 

POW  is  responsible  for  processing  only  the  proposals  of 
qualified  vendors.  The  first  filter  to  catch  the  non- 
qualified vendors  is  during  the  RFP  process.  The  second 
filter  is  during  checking  and  verification  of  new  vendors, 
and  the  third  filter  is  during  the  Pre-Award  Survey. 
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D.   GOVERNMENT  PROCUREMENT 

1  .   Foreign  Military  Sales  (FMS) 

a.  Background 

The  United  States  has  been  assisting  friendly 
countries  in  establishing  adequate  defensive  forces  for 
their  national  security  and  for  resisting  external 
aggression.  This  policy  is  essential  to  the  security  of  the 
U-S  A  itself. 

b.  FMS  Important  Issues: 

(1)  No  commercial  export  license  may  be  issued  for  the 
sale  of  major  defense  equipment  valued  at  $25 
million  or  more,  except  through  an  FMS  case. 

(2)  The  President  of  the  USA,  30  days  prior  to  giving 
his  consent  for  sales,  must  submit  to  the  Speaker  of 
the  House  of  Representatives  and  Committee  on 
Foreign  Relations  of  the  Senate  ,  a  written 
certification  of  the  proposed  arms  sale.  The 
Congress  may  veto  this  proposed  transfer.  Further- 
more, the  certification  submitted  to  the  Congress 
shall  be  unclassified  (classified  information 
submitted  separately)  to  permit  public  disclosure. 

(i)  The  cost  and  interest  to  be  charged  to  the  foreign 
country  will  include  administrative  services,  plane 
and  production  equipment  cost,  and  a  proportionate 
amount  of  any  nonrecurring  cost  of  R  &  D. 

(4)  Commercial  sales,  through  export  licenses, of  major 
defense  systems  are  limited  of  the  value  of  $25 
millions.   LRef.  6] 

c.  FMS  Authority  Distribution 

Figure  2.22  shows  the  inter-relations  between 
the  USA  authority  in  FMS.  The  following  are  the  role  of  the 
main  USA  authoroties  envolved  in  this  system. 
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(1)  Congress .  ■  Their  are  various  laws  for  the 
purpose  of  guiding  and  controlling  the  FMS  process.  One  of 
the  key  laws  is  that  the  President  of  the  United  States  must 
submit  to  the  Congress,  30  days  prior  to  his  consent,  every 
proposed  sale  that  exceeds  $25  million.  Moreover,  the 
Congress  requires  annual  reports  from  the  President  on  the 
status  of  FMS    [Ref.  14]. 

(2)  State  Department.  The  State  Department  is 
primarily  concerned  with  U.S.  security  policy  all  over  the 
world,  and  so  established  the  Bureau  of  Politics  -  Military 
Assistance  [Ref.  7].  This  Bureau  generates  policy  guidance 
and  procedures  concerning  the  issues  of  USA  security,  FMS 
and  arms  control.  Within  the  bureau  their  are  three  offices 
that  maintain  constant  contact  with  the  DoD  and  other 
departments  as  necessary  for  the  approval  of  military 
exports.  The  three  offices  are: 

Office  of  Security  Assistance  and  Sales  (SAS) 

Office  of  Munitions  Control  (OMC) 

-    Office   of   Planning   and   Analysis  for  International 
Secur i  t y . 

(3)  Department  Of  Commerce.  The  Department  of 
Commerce  is  primarily  responsible  for  the  overall  economic 
growth  and  technical  development  of  the  USA.  Within  the 
department,  the  office  that  maintains  inter-departmental 
discussions   affecting   t.he  international  trade  is  the  office 
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of   Domestic   and   Business  Administration  (DIBA).This  office 

is  concerned  especially  with:  [Ref.  14] 

Competitive   assessment   of   US   industry  in  domestic 
and  world  markets. 

Expansion     of     export     and     export     control 
admin  istration  . 

Federal    recognition   and   participation   in   inter- 
national exposition  and  trade  fairs. 

( 4 )  Department  of  Treasury .  The  Department  of 
Treasury,  in  the  area  of  foreign  trade,  participates  in  the 
financial  negotiations  between  the  US  and  foreign  countries. 
It  exercises  broad  control  over  military  and  commercial 
export  programs,  assuring  that  they  are  compatible  with 
the  US  trade  and  security  policy.  It  also  reviews  trade 
agreements  for  credit  risk  evaluation,  assuring  the  best 
utilization  of  US  Government  backing  to  credit  institutions 
[Ref.  21  J . 

(5)  Department  of  Defense  (DoD).  The  DoD  is 
the  principal  actor  involved  in  FMS.  The  DoD  serves  as  the 
main  co-ordinator  for  all  the  objectives  of  the  other 
departments  concerning  FMS.  There  are  four  major  offices 
involved  in  military  assistance  and/or  the  sale  of  military 
items  :    [Ref.  14] 

-  Defense  Security  Assistance  Agency  (DSAA)  DSAA 
Serves  within  the  DoD  as  the  responsible  office  for 
Government  to  Government  FMS,  performed  under  the  control  of 
the  Secretary  of  Defense.  It  was  established  in  1971  and  has 
been    responsible    since    then    for   the   generation,   and 
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maintenance    of    procedural    guidance    according   to   the 
Military   Assistance  and  Sales  Manual,  DoD  Manual  5105. i8-M 

[Ref.  7J.  In  addition  to  participation  in  top  level 
planning,  programming,  and  reviewing  of  FMS.  DSAA  performs 
the  following  functions:  [Ref.  7] 

*  Conducting  negotiations  with  the  customers. 

*  Interfacing  with  and  assisting  US  industry,  in 
its  effort  to  receive  export  licenses  from  the 
State  Department  for  doing  business  with  foreign 
countries . 

*  Managing  FMS  credit  arrangement  and  guarantees 
of  private  financing  of  FMS. 

Office   of   Assistance   Secretary   of   Defense   for 

International  Security  Affairs  (QASD/ISA).  The  OASD  (ISA) 

develops   policies   concerning  international  security  through 

a   mutual  agreement  with  the  State  Department.  Within  ISA  the 

Deputy   Assistance   Secretaries  (Regional  desks),  provide  and 

prepare   for   their   regions  a  threat  analysis  for  a  specific 

country   based   upon   its   potential  enemies  and  the  military 

capabilities   of   both  sides.  The  Director  of  Strategic  Trade 

and   Disclosure   within   ISA  provides  official  DoD   positions 

on   any   proposed   military   or   commercial   exports  that  has 

possible    military   application.   This   is   accomplished   in 

coordination   with   Department   of   Commerce   and   the   State 

Department.   The  review  of  any   export  license  is  done  by  the 

Inter-agency   Board   consisting   of   representatives  from  the 

Department   of   State,   Department  of  Commerce,  Department  of 

Treasury  and  the  Director  of  Strategic  Trade  and  Disclosure. 
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Elements  of  the  Armed  Forces  and  JCS.  The  State 
Department's  Office  of  Munitions  Control  (OMC),  submits  the 
export  application  of  the  foreign  country  to  the  concerned 
service  Army  (Director  of  International  Logistic),  Navy 
(Security  Assistance  and  Sales).  Each  service  has  major 
functions  to  achieve  related  to  FMS:  [Ref.  14] 

*  Upon  receipt  of  the  export  application,  through 
the  DoD  Director  of  Strategic  Trade  and 
Disclosure,  it  formalizes  and  presents  its 
position  . 

*  It  provides  the  detailed  analysis  and  evalua- 
tions that  are  necessary  for  the  negotiation 
process  . 

*  It  assists  DSAA  in  the  process  of  the 
negotiations. 

*  It  manages  and  administrates  the  sales  activity 
during  its  performance. 

2 .   Egyptian  Government  Procurement  from  USA 

The  major  two  kinds  of  military  procurement  from  the 
USA  are  the  Government  procurement  of  Major  Defense  Items 
and  the  Spare  Parts  Procurement  for  Weapons  already  in 
service  and  purchased  from  the  USA.  Both  kinds  of  procure- 
ment must  be  processed  according  to  the  USA  FMS  rules  and 
regulations.  Major  defence  items  procurement  such  as 
aircraft,  tanks,  and  air  defense  weapons  is  lengthy 
procedure.  POW  must  be  alert  and  responsive  to  speed  up  this 
process  during  its  performance. 

The  POW  acts  as  a  co-ordinator  between  AA  and  the 
USA    Security    Assistance    Center    (SAC),   which   is   the 
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responsible  organization  inside  the  USA  Government  for 
administrating  the  requests  of  friendly  foreign  countries  to 
purchase  major  defence  items  and  military  equipment.  The  FMS 
policy  procedures  must  be  well  understood  to  speed  up  this 
kind  of  procurement.  A  network  of  interrelation 
responsibilities  starting  from  the  President  of  USA, 
Congress,  Department  of  State,  Department  of  Treasury, 
Department  of  Commerce,  and  Department  of  Defense  are  all 
involved  in  processing  the  requests  of  major  defence  items 
purchases.  Many  factors  must  be  considered  in  doing  this 
kind  .  of  procurement.  The  political  issues  also  have  a  great 
effect  on  this  kind  of  procurement. 

The   following   details  the  steps  in  the  two  kinds  of 
Government  procurement.  (Figure  2.23) 

a.   Major  Weapons  Systems  Procurement  Steps 

The  basic  document  in  this  kind  of  procurement 
is  the  Letter  of  Offer  and  Acceptance  (LOA)  (DD  FORM  1513). 
The  LOA  is  also  known  as  a  "Request  Of  Sale"  or  "Request 
For  Price  and  Availability".'  After  the  acceptance  of  the 
LOA  by  the  USA  Government,  it  becomes  a  contract  between  the 
two  countries.  The  Government  procurement  consists  of  eight 
steps  initiated  by  submitting  the  Request  for  Letter  of 
Offer  (RLO).  All  USA  Forces  have  similar  procedures  for  the 
FMS.  The  following  procedures  are  based  on  the  Air  Force  FMS 
(U.S.  Department  of  the  Air  Force,  "  logistics  -  Foreign 
Military  Sales"  AFM  400-3,  17  Feb  1976),   LRef.  Qj. 
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Figure  2.23  Organizational  Slructure  for  Receiving  and  Processing  a 
Request  for  Offer  and  Acceptance     [Ref.  21] 
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The   RLO   must   be   prepared   and   reviewed   very 

carefully   by   the   Top  Level  in  Egyptian  Minister  of  Defense 

(MoD),   AA,   and   the   Major  Armed  Forces.  A  special  Forms  of 

RLO   must   be   prepared   known   as   a  "  Checklist  for  weapons 

system  sale  request. 

The   following  are  example  of  the  USA  Air  Force  Checklist 
Main  subjects; 


Country 

Aircraft  Model / Des i gnator/ Ser ies/  (MDS) 

Quantity 

Basic  Configuration 

Sou  r ce  Data 

Delivery  Data 

Missiles/ECM  Pods/ Bombs/ Ammo 

Anticipated  LOA  Acceptance 

Operational  Concepts 

Maintenance  Concepts 

Supply  Concepts 

Contractor  Engineering  and  Technical  Services  (CETS) 

Weapons    Systems   Logistics   Officers   (WSLO)/System 

Acquisition  Officer  (SAO) 

Training  Concept 

Insurance 

Quality  Assurance 

Other  Pertinent   Remarks 
SOURCE   of  this  checklist  is:  AFM  400-j(R),  Attachment  d, 
17  February  1976. 

Negotiations   and   discussions   are   held  between 
the   representatives   of   the   two   countries   to  clarify  the 
requirements   of   Egyptian   Armed   Forces  and  the  assessments 
for  the  acquisition  request.  The  POW  Chief  officer  particip 
ates  in  these  meetings. 

The   final   form   of   the  RLO  is  submitted  to  the 
Defense  Security  Assistance  Agency  (DSAA). 
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The  following  are  the  steps  for  procuring  the 
major  Defence  Items: 

(1)  Submit  the  RLO  to  DSAA.  The  DSAA  requests 
the  Related  H.Q.  for  its  position  on  the  request. 

( 2 )  Assign   Case   Designator   and  Request  Price 
and   Availability.   ROW   receives   acknowledgment   of  receipt 
from   the   related   H.Q.,   at  the  same  time  the  H.Q.  asks  the 
Various   commands   for   their  Price  and  Availability  (P  &  A). 
[Ref  .  6] . 

( 3 )  Determination   of   P   &  A  and  Submission  to 
the   .related   H.Q.     The  various  commands   prepare  the  P  i  A 
within  jO  days  and  submit  it  to  the  H.Q. 

( 4 )  Preparation  of  the  Offer  and  Acceptance. 
Upon  receipt  the  P  &  A  from  the  various  commands  of  the 
related  H.Q.  prepares  the  complete  LOA.  Any  LOA  in  excess 
of  $25  million  or  sales  of  major  defense  item  in  excess  of 
$7  million  must  be  submitted  to  the  director,  DSAA,  who  in 
turn  must  notify  the  Congress.  If  the  Congress  does  not 
adopt  a  concurrent  resolution  objecting  to  the  sale  within 
30  days,  the  DSAA  authorizes  the  H.Q.  to  sign  and  issue  the 
LOA  to  the  requesting  country    [Ref.  7]. 

( 5 )  Review,  Acceptance  and  Funding  of  the  Offer 
and   Acceptance.   POW  receives  the  LOA  and  sends  it  to  AA  for 
reviewing   which  must  sign  it  within  30  days  from  the  date  of 
receiving   the  offer.  If  AA  accepts  the  offer,  the  signed  LOA 
is  returned  to  the  POW  who  in  turn  sends  it  to  the  DSAA. 
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(6)  Provide  Case  Directive.  Upon  receipt  of 
the  acceptance  of  the  LOA,  the  H.Q.  issues  case  directives 
to  the  participating  Major  Commands  and  implementing 
agencies.  The  case  directives  include:  [Ref.  7] 

Financial  aid 

Delivery  terra  code 

Force  Activity  Designator  (FAD)  or  priority 

-  Purchaser's  service  code 

-  Nonrecurring  cost 
Asset  use  charge 

-  Sales  comraissionsand  contingent  fees 

-  Any  special  instructions 

( 7 )  Furnish   Material   or   Services   and  Notify 
therelated   Force   accounting   And  Finance  Center.  (Air  Force 
Example   )   The   major  commands  and  the  implementing  agencies 
that   take   actions  based  on  the  regulations  in  AFM  400-j  are 
[Ref.  6] : 

-  Air  Forces  System  Commands   (AFSC) 
Air  Force  Logistics  Command  (AFCTC) 
Air  Force  Training  Command  (AFTC) 
Tactical  Air  Command   (TAC) 

Air  Force  Accounting  and  Finance  Center    (AFAFC) 

Following    these   actions,   procurement   and 
budget  authorizations  are    obtained. 

(8)  Billing  the  Customer.  This  is  the  last 
step  in  the  processing  of  the  foreign  military  sales, 
concerning  the  billing  and  terms  of  payment s.  Like  the 
commercial   procurement,  there  are  two  sources  of  funding  the 
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government   procurement:   Budget  and  Loans.  The  procedure  for 
payment  is  very  similar  to  the  commercial  procurement. 

Conclusion .  The  FMS  procedures  are  complex  and 
lengthy  but  nevertheless  logical  and  structured.  The 
Congress  has  full  control  over  the  procurement  requests 
which  exceed  $  25  million  or  for  Major  Defense  items  that 
exceed  $7  million. 

DoD  implements  the  FMS  through  major  services  usin^,  the 
LOA  D.D.  Form  1513  as  a  contract  document  between  the  USA 
and  the  foreign  country.  This  document  specifies  the  terms 
and  obligations  concerning  the  two  governments  in  processing 
and  implementing  the  procurement  system, 
b.   Spare  Parts  Procurement 

This  kind  of  procurement  is  oriented  towards 
weapons  already  purchased  and  in  the  service  of  the  Egyptian 
Armed  Forces.  The  FMS  system  for  this  kind  of  procurement 
is  divided  into  two  parts:  FMS1  and  FMS2 

(1)  FMS 1 .  Represents  an  amount  of  money  paid 
by  the  Egyptian  Government  to  participate  in  sharing  the 
cost  of  the  inventory  of  spare  parts  to  serve  all  countries 
which  have  purchased  weapons  from  USA.  The  FMS1  system  keeps 
track  of  inventory  of  all  kinds  of  spare  parts  ready  on  the 
shelf  to  serve  all  participating  countries.  It  uses  advanced 
scientific  technique  to  prevent  any  shortage  of  spare  parts. 

(2)  FMS2 .  Represents  an  amount  of  money  to 
cover   the   yearly   requisitions  of  the  spare  parts  needed  by 
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the  EGAF's.  Requisitions  from  the  system  may  be  done  on  a 
daily  basis  in  a  precisely  structured  computer  format  that 
allow  processing  of  every  single  item  separately.  POW  has 
nothing  to  do  with  the  implementation  of  the  system,  except 
receiving  and  sending  any  related  system  documents  to  both 
sides.  Charges  to  the  system  are  done  by  the  POW  upon 
receipt  of  an  authorized  payment  letter  from  the  AA. 
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Ill .   PROBLEMS  AND  OPPORTUNITIES  IN 
THE  PQW  CURRENT  SYSTEM 

A.  INTRODUCTION 

This  Chapter  identifies  the  problems  and  opportunities 
of  the  PQW  relevent  to  developing  a  data  driven  DSS.  In  the 
problem  part,  we  address  the  system  wide  problems  first  and 
then  describe  any  problems  in  each  particular  function,  if 
any.  In  the  opportunities  part  of  this  section,  we  describe 
in  some  details  what  computers  and  databases  can  do  for 
improving  the  existing  functions  of  the  ROW  current  system. 
It  should  be  noted  that  the  solutions  for  all  of  these 
problems  will  not  be  covered  in  this  research  because  of  the 
time  constraint;  rather  we  will  emphasize  the  detailed 
design  of  the  commercial  procurement  functions  .  The  inten- 
tion is  to  present  all  the  problems  and  opportunities  of  the 
POW  uncovered  during  interviews  with  the  POW  specialized 
officers  . 

B.  SYSTEM  WIDE  PROBLEMS 

The  POW  is  the  central  point  of  receiving  all  the 
requests  of  EGAF's  for  procurement  of  military  items  and 
weapon  systems  from  the  USA.  Because  of  continued  increasing 
demands  from  the  USA,  the  workload  in  POW  is  now  increasing 
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exponentially.   The   system   is   designed   to   deal  with  much 
smaller  demand  than  currently  exists. 

The  existing  manual  system  needs  to  be  developed  and 
supported  by  computer  tools  to  enhance  its  capability.  The 
system  wide  problems  with  the  manual  system  are: 

1.  Too   much   effort   and   time   needed   for   the  manual 
tasks  . 

2.  Some   functions  cannot  be  done  in  a  reasonable  length 
of  time. 

3.  Generating  '  status   reports  is  getting  more  difficult 
without  computer  tools. 

We   follow   exactly   the   structure   of   Chapter.   II   to 

describe   the   problems   and   opportunities   of   each   system 

function  presented  in  that  chapter. 

C.   COMMERCIAL  PROCUREMENT  FUNCTIONS 
1  .   RFP's  Function 

a .  Problems 

Too   much  effort  and  time  needed  for  the  prepara- 
tion of  vendor  list  for  a  particular  RFP. 

b .  Causes : 

(1)  Large  number  of  RFP's 

(2)  The   RFP   received   is   not   in   a  standard  format  to 
allow  easy  accessing  to  the  vendor  data. 

(j)  Large   number   of   vendors  available  in  USA  to  select 
from  . 
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c.   Opportunity 

Building  a  database  for  vendor  information 
allows  better  processing  of  the  RFP's  and  decrease  the 
vendor  selection  time  for  a  particular  RFP. 

2 .  RFC  Function 
a.   Problems 

No  problems  are  addressed  in  this  function, 
c .   Opportunity 

-.  A  DSS  can  be  used  as  a  tool  for  evaluating 
proposals  and  vendor  selection.  The  guidelines  to  the  system 
are: 

(1)  Multiple  evaluation  factors  are  established  and 
weighted. 

(2)  Each  proposal  is  scored  by  the  technical  committee 
using  these  factors  . 

(i)  The  system  should  allow  presentation  of  information 
to  the  evaluators  in  different  formats  including 
graphs  and  utility  analysis. 

3 .  Fund  the  contracts: 

This  part  include  the  both  budget  and  loan  funding. 

a .  Problems  : 

Too  much  effort  needed  to  manage  the  funding 
functions. 

b .  Causes  : 

(1)  All  contracts  with  vendors  in  USA  must  be  funded  via 
POW,  a  large  volume  needs  to  be  funded,  over  500 
contracts  . 

(2)  Monitor  all  credit  and  guarantee  letters  associated 
with  contracts;  it  represents  large  volume,  over 
1500  of  different  letters  with  different  banks  and 
different  vendors  interacting  in  this  process. 
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c.   Opportunity: 

(1)  This  process  has  a  potential  for  automation.  An 
automated  system  will  allow  better  control  of  tnis 
process  by  producing  status  reports  of  all  tne 
credit  and  guarantee  letters  .  Warning  reports  can 
be  produced  for  renewal  validity  dates  of  the 
guarantee  letters 

(2)  Establish  Financial  management  system  to  monitor 
funds  from  loans,  especially  unused  loans  which  may 
have  a  limited  time  of  valid i ty .  Effect i ve  use  of 
funds  from  loans  depends  on  timely  decisions 
concerning  use  of  this  fund.  The  decision  process 
related  to  the  effective  use  of  available  loans  is 
very  important  to  the  EGAF ' s .  POW,  as  a  front  office 
can  assist  the  AA  by  producing  status  and  comparison 
reports  of  the  fund  availability  from  loans.  Passing 
this  information  to  AA  ahead  of  time  to  take  the 
necessary  actions  before  the  end  of  validity  date  is 
very  important.  This  one  benefit  of  the  system  may 
cover  many  times  the  cost  of  building  the  system. 

■  4 .   Administer  open  contracts 

a.  Problems 

All  the  problems  of  any  manual  system  are 
figured  in  this  system  to  some  degree  or  another.  High 
volume  of  paper  work,  slow,  data  redundancy  ,  spending  more 
time  and  effort  to  do  the  function,  etc. 

b .  Causes 

The  problems  in  this  function  are  due  to  the 
fact,  that  the  manual  sy-stem  lacks  the  capability  of  the 
computer  system  with  respect  to  the  routine  and  repetitive 
work.  The  POW  staff  tries  to  keep  the  system  running  by 
spending  more  effort  and  time.  The  four  sub- f unc t i on s  of  the 
open  contract  adminstration,  payment,  shipment  monitoring 
personnel  training,  and  reporting  form  four  sub-systems 
which  have  a  great  potential  for  automation. 
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c.   Opportunity 

(1)  Payment .  The  payment  process  involves  the 
technical  and  financial  checking  and  validation  based  on  the 
contract,  invoice,  shipment  receipt,  necessary  certificates, 
vendor  performance  etc.  Everything  must  be  checked  before 
payment  is  made.  To  speed  up  the  decision  related  to  this 
function,  a  computer  tool  is  a  must.  By  developing  such  a 
system,  the  specialized  officer  can  easily  validate  the 
payment  documents.  In  the  design  chapter  we  present  a 
proposed  system  for  these  functions. 

( 2 )  Monitor  Shipment  of  Items  to  the  Country. 
POW_  has  an  access  terminal  to  the  Freight  Forwarder 
computer.  This  system  can  be  improved  by  allowing  transfer 
of  the  summary  data  about  the  shipment  status  to  the  FUCUS 
database.  This  function  is  included  in  this  research  and  may 
be  expanded  later. 

(3)  Monitor  Personnel  Training.  A  considerable 
amount  of  work  needs  to  be  done  by  the  POW  to  monitor  the 
training  of  personnel.  All  open  contracts,  commercial  or 
government  procurement,  have  a  training  part  which  needs  to 
be  scheduled  on  time.  POW  must  inform  AA  ahead  of  time  of 
the  training  plan  associated  with  each  contract  to  have 
enough  time  for  selecting  and  preparing  personnel  who  will 
attend  the  training  programs  in  the  USA.  On  the  other  hand, 
all  personnel  affairs  in  the  USA  are  the  responsibility  of 
POW   e.g.   monthly  salary,  traveling  reservation  and  tickets, 
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and  medical.  This  function  can  also  be  automated.  The 
database  allows  easy  system  development  of  such  functions  to 
monitor  and  control  all  training  in  USA. 

(U)  Reporting.  A  database  system  is  a  powerful 
tool  for  generating  different  kinds  of  reports.  In  PC/FOCUS, 
the  reporting  facility  is  excellent.  It  allows  user  to 
generate  any  kinds  of  reports  they  need  from  the  database  in 
seconds  without  programming.  The  reporting  and  graphics 
facilities  in  PC/FOCUS  provide  a  valuable  DSS  tool  for 
presentation  of  information. 
5 .   Generate  Vendor  List 

This   function   is   necessary  for  the  RFP's  function.' 
We   separate   it   here   because  of  its  special  importance.  We 
have    to   deal   only   with   potential   vendors   in   the   USA 
industry. 

a.  Problems 

The  manual  vendor  list  is  time  consuming,  for 
example,  135,000  US  manufactures  are  exist  in  Thomas 
Register,  over  500  vendors  have  contracts  with  POW. 

b.  Causes 

Many  sources  are  used  to  generate  a  vendor  list: 
vendors  who  already  have  contracts  with  POW,  vendors  suggest- 
ed by  AA  for  a  particular  RFP,  vendors  responding  to  an 
advertisment  in  the  newspaper,  vendors  responding  to  RFP's, 
vendors   supplier  to  the  USA  Army/ Navy/ Air  Force,  and  vendors 
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from   Thomas   Register   catalog.   The   investigation   process 
requires   much   time   to   check   the   Qualification   Form  and 
verify  it  from  market  research  associations. 
c .   Opportuni  ty 

The  potential  for  automation  is  very  high. 
Putting  vendor  information  in  a  database  is  essential  for 
the  POW  function.  The  cost  of  selecting  bad  vendors  is  much 
higher  than  the  expected  cost  to  develop  any  system  to  keep 
and  maintain  information  about  vendors.  POW  has  a  major 
responsibility  in  selecting  and  validating  vendors  before 
passing  their  proposals  to  AA ,  even  those  suggested  by  the 
AA  with  a  particular  RFP.  vendor  selection  criteria  must  be 
applied  in  all  the  procurement  phases.  Creating  a  database 
for  vendors  will  allow  the  specialized  officer  to  prepare 
the  vendor  list  in  a  fraction  of  time  needed  for  the  manual 
system . 

D.   GOVERNMENT  PROCUREMENT 

As  we  mentioned  in  describing  this  process,  POW  acts  as 
a  co-ordinator  between  AA  and  USA  administration. 

1.   Procurement   steps   for  the  major  Weapons  system   The 

Government   procurement   cycle   is  mainly  done  inside  the  AA 

and  the  USA  administration.  POW  serves  essentially  as  a 
communication  link  between  the  two. 


74 


a  .   Problems : 

(1)  How   to   speed  up  the  process  from  submitting  the  RLO 
■  until  we  get  the  LOA  ? 

(2)  How  to  monitor  the  performance  of  the  Egyptian  Major 
Weapons  System  Contracts  (EGWSC)  managed  by  the  USA? 

b .  Causes : 

(1)  The  FMS  procedures  are  complex. 

(2)  A  network  of  interrelationships  are  involved  in  the 
FMS  process  including  the  President  of  USA, 
Congress,  and  many  Departments. 

(j)  Inside  DoD,  many  H.Q.  commands  are  involved  in 
processing  a  particular  RLO.  Many  rules  and 
procedures  must  be  followed. 

c.  Opportunity 

Weapons  Acquisition  is  very  critical  function  to 
Egypt.  Getting  the  necessary  defense  weapons  is  of  vital 
importance.  The  time  to  process  the  RLO  is  far  toolong. 
Monitoring  implementation  of  weapons  system  projects  is  very 
important.  Building  a  decision  support  and  monitoring 
system  will  be  of  a  great  help  in  answering  the  above  two 
questions.  POW  is  the  most  suitable  organization  to  do  this 
function,  because  of  its  position  as  a  co-ordinator  or  linK 
between  the  EGAF ' s  and  the  USA  administration.  Two  database 
may  be  needed,  one  for  the  acquisition  phase  i.e.  the 
activities  starting  from  submitting  the  RLA  until  getting 
the  LOA.  The  other  is  for  the  implementation  phase  to 
monitor  all  the  current  projects  managed  by  USA  administra- 
tion for  the  benefit  of  Egypt.  These  two  sub-systems  will 
be  of  great  help  in  speeding  up  the  acquisition  process  by 
pointing   up   any   delay,  and  by  providing  the  data  needed  by 
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USA  rapidly.  By  building  an  information  system  to  monitor 
Government  procurement  from  USA,  we  put  a  foundation  of  the 
DSS  in  the  Weapons  Acquisition  System  (WAS),  itself. 
Knowing  the  FMS  policy  and  procedures  are  very  important  in 
building  this  system.  All  the  technical  References  related 
to  the  FMS  system  must  be  available.  Technical  support  from 
USA  may  be  needed  to  build  that  system. 
2 .   Spare  Parts  Procurement 

No   Problems   and   Opportunities   related   to  POW  are 
perceived  by  the  author  in  this  study. 
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.IV.  SOFTWARE  REQUIREMENT  SPECIFICATION  OF  PQW 

A.   INTRODUCTION 

The  objective  of  this  chapter  is  to  analyze  the  informa- 
tion flow  as  presented  in  chapter  II,  and  create  the  soft- 
ware requirement  specifications  for  the  ROW  Commercial  Procu- 
rement (POWCP)  system.  The  specification  presented  in  this 
chapter  will  emphasize  on  the  creation  of  the  DSS  generator 
for  the  POWCP  database. 

The  DSS  generator  is  a  set  of  of  interpreters  and  data 
creation  utilities.  DSS  tools  are  used  to  build  and 
modify  the  interpreters.  [Ref.  1] 


B.   REQUIREMENT  ANALYISIS  OF  POWCP  PROPOSED  SYSTEM 

The   following   are   the   primary   objectives  of  the  POWCP 

proposed  system  : 

-    Increase   functional   performance   efficiency   of  the 
POWCP  system. 

•-    Assist  decision  making  process  in  the  POWCP  system. 

We   recognized   from   chapter  II  and  chapter  III  that  the 

POWCP   has   a   high-payoff   area   for   decision   support.   To 

capture   the   benefits   of   this  high-payoff,  we  are  going  to 

use   the   Iterative   Design  approach  'Staged  Development'  r  or 

building   a   prototype   DSS   for  the  POWCP.  The  following  are 

the  expalanation  of  the  approach  as  presented  in  [Ref.  IJ: 

DSS  need  to  be  built  with  short,  rapid  feedback  from 
users  to  ensure  that  development  is  proceeding  correctly. 
They  must  be  developed  to  permit  changes  quickly  and 
easily.  The  result  is  that  the  most  important  four  steps 
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in  the  typical  systems  development  process  (analysis, 
design,  construction,  implementation)  are  combined  into 
a  single  step  which  is  iteratively  repeated.  The  essence 
of  the  approach  is  that  the  user  and  the  builder  agree 
on  a  small  but  significant  problem,  then  design  and 
develop  an  initial  system  to  support  the  decision  making 
that  it  requires.  After  a  short  period  of  use  (a  few 
weeks),  the  system  is  evaluated,  modified,  and 
incrementally  expanded.  This  cycle  is  repeated  three  to 
six  times  over  the  course  of  few  months  until  a 
relatively  stable  system  is  evolved  which  support 
decision  making  for  a  cluster  of  tasks.  The  word 
relatively  is  important,  because  although  the  frequency 
and  extent  of  changes  will  decrease,  it  will  never  be 
stable.  The  system  will  always  be  changing,  not  as 
necessary  evil,  but  as  a  conscious  strategy  on  the  part 
of  user  and  builder. 

The   advantages   of   using   this  approach   are:  Leads  to 

development   of   DSS   Generator,  gives  early  success  and 

visibilty.   Allows   overlapping  of   different  staged  DSS 

and  integration  between  them,  ability  to  assimilate 
evolving  technology.   [Ref.  1] 

To  realize  the  benefits  of  this  approach,  we  must  be 
concerned  about  the  time  of  development.  It  should  be  as 
short  as  possible  (2-3  months  maximum  for  the  first  version) 
prepare  an  action  plan,  for  development,  divided  into  phases, 
build  the  DSS  generator,  use  the  structure  approach  in 
analysis  and  design  of  DSS  to  be  able  to  maintain  and  adapt 
the  system  during  each  stage,  finally  we  should  use  available 
software  as  we  did  in  PC/FOCUS. 

The  approach  used  to  describe  the  proposed  system  is  to 
follow  the  logical  sequence  for  each  function  and  describe 
each  process  associated  with  the  improved  DFD.  The  secondary 
process  for  a  particular  function  is  described  at  the  end  of 
the  function.  Because  our  priority  is  to  build  the  DSS 
generator  first,  i.e.  the  database,  we  first  apply  the  data 
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analysis  technique  (See  data  dictionary  section,  chpter  V.) 
to  derive  the  database  structure  in  third  normal  form  before 
designing  the  database  file  as  described  in  the  following 
chapter.  The  disk  media  symbol  used  to  indicate  the  proposed 
database  files.  Only  the  functions  or  processes  to  be 
automated  are  explained  in  the  following  sections. 

1.  RFP  Functions  Description.  The  fuction  is  divided 
into  sub-fuctions  and  process,  expalanation  of  each  one  are 
presented  as  necessary  . 

-  Process  1.1;Prepare  &  issue  the  RFP.  Figure  4.2 
shows  the.  details  of  the  process. 

-  Procsessl.1.1  Receive  &  review  the  RFP.  Figure  4.j 
shows  the  premitive  level  of  DFD.  The  following  are  a  walk- 
through for  each  process.  The  same  sequence  of  will  be  used 
to  explaine  the  other  functions 

Process   1.1.1.1 Register  RFP .  The  purpose  of  this 

function  is  to  register  each  particular  RFP  in  the  General 
Log  Book  (GLB)and  the  RFP  Control  Book  (RFPCB).  he  code 
used  to  register  the  RFP,  or  any  incoming  documents  to  POW 
consists  of  a  six  digit  serial  number  starting  at  one  at  the 
beginning  of  the  year  and  incremented  by  one  for  each 
incoming  document.  This  number  will  be  used  as  a  key  when 
recording  the  information  about  the  major  documents  received 
or   issued   from   POW.   The  information  items  kept  in  the  GLB 


are 


*  Registration  Number    *    Date  Received 

•  Source  and  subject 
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Figure  4.2    Prepare  &  Issue  the  RFP 


The   RFP   is   then   routed  to  the  Specialized  Officer 
(SO)  in  the  area  of  specialization. 

-  Process   1  ,  1  ,  1  ♦  2 Review   and   Checks   RFP.   The  SO 

reviews  and  checks  the  specification.  This  process  is 
subjective  and  relies  on  the  capabilities  of  the  SO. 

Process   1.1.1.3 Enter  RFP  in  the  Database.   Enter 

the  RFP  data  in  the  database  through  screens.  The  following 
are  the  data  related  to  a  typfcal  RFP: 

*  RFP  Number 

*  Received  date 

*  Requester  (Force  or  Department) 

*  RFP  subject 

*  I  terns  needed 

*  Item  description 

*  Unit  of  Issue 

*  Quantity 

*  Estimated  Dollars  value 

*  Terms  and  conditions 

*  Vendors  who  receive  the  RFP 

*  Vendors  who  send  Proposals  data. 
(Normalization   of   data   will   be   done   in   next   chapter.) 

-  Process 1.1.2 Select   Vendors   to   Receive   RFP. 

Selection  of  vendors  to  receive  the  RFP  are  done  only  from 
the  qualified  vendor  in  the  Vendor  Database.  Creation  of  the 
vendor  database  is  described  at  the  end  of  this  section. 
(Figure  4.4) 
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Process   1.1.2.1 Match   Item   Classes.     Match   a 

particular  RFP's  item  classes  with  the  item  classes  in  the 
vendor  database.  This  process  is  done  by  the  computer  to 
produce  a  primary  list  of  vendors  who  are  relevant  to  the 
RFP.  The  SO  may  repeat  this  process  using  other  item  classes 
until  he  is  satisfied  with  the  vendor  list  produced.  The 
vendor  list  may  look  as  follows; 


RFP-NO: 

VENDOR 
ID 


VENDOR 
NAME 


VENDOR  LIST 


POINT  OF 
CONTACT 


VENDOR 
ADDRESS 


PHONE 
NO 


ITEM 
CLASS 


Process   1.1.2.2 Check  Vendor  Details.   The  SO  may 

wish  to  access  the  detailed  data  about  a  particular  vendor. 
He  can  do  that  by  retrieving  the  vendor  record  using  the 
vendor  ID.  If  he  wants  more  details  about  the  vendor  company 
such  as  its  profile  or  brand  names  etc.,  he  may  refer  to  the 
Thomas  Register  or  any  other  reference. 

Process   1.1.2.3 Approve   the   Final   Vendor  List. 

The  SO ' s  must  approve  all  vendor  lists  generated  by  any 
means  (computer  or  manual)  from  the  POW  Director  before 
mailing  it  to  vendors  with  the  RFP  copies. 
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Process  1.1.3   Mail  RFP  to  Vendors. 

-  Process    1.1.3.1 Produce   Vendor   Mailing   List. 

This  process  may  be  done  either  manually  or  by  computer  to 
prepare  the  mailing  label  of  vendor  address  and  point  of 
contact.  (Figure  4.5) 

-  Process   1.1.3.2 Issue   the   RFP   to   Vendors.    A 

number  of  copies  of  the  RFP  are  produced  using  electronic 
copier  machine  and  mailed  to  the  vendors.  The  information 
about  vendors  who  get  the  RFP  is  recorded  in  the  computer 
and  the  RFPCB.  The  following  is  the  data  structure  of  the 
RFPC3  to  be  recorded: 

*  RFP  Number 

*  RFP  Copy  Number   (a  serial  number  within  RFP 

*  Vendor  ID 

*  Vendor  Name 

*  Date  of  Issue  to  Vendors 

-  Process  1.2   Receive  Proposals. 

-  Process  1.2.1   Receive  and  Record  Proposals. 

-  Process   1.2.1.1 Register  Proposals.   All  incoming 

proposals  are  registered  in  the  GLB  and  RFPCB.  A  register 
number  is  given  to  each  proposal  in  the  GLB.  The  data 
elements  to  be  recorded  are: 

*  RFP   Number  *  Proposals  Serial  Number 

*  Vendor  Name  *   Date  of  Received 

*  Proposals  description 
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Process   1.2.1.2 Check   and  Review  Proposals.   The 

SO  reviews  and  checks  all  the  incoming  proposals.  The 
proposals  from  new  vendors  are  put  in  a  pending  file  until 
the  qualification  process  is  done.  The  non  relevant 
proposals  and  the  non-qualified  vendors  proposals  are 
discared.  The  relevant  proposals  from  the  qualified  vendors 
are  put  in  a  pending  file  until  closing  date  of  RFP  is  over. 

Process    1.2.1.3 Record   Proposals.     The   basic 

proposals  data  are  recorded  in  the  Proposals  Monitor  File 
(PMF).  The  data  to  be  recorded  are: 

»    RFP  Number 

*  Proposals  Serial  Number  (within  the  RFP  number) 

*  Vendor  Name 
»    Vendor  ID 

*  Proposals  Received  Date 

*  Total  Value  Of  Proposals 

Process    1.2.2 Issue   Qualification   Form.   (QF) 

QF's  are  issued  to  new  vendors.  Their  proposals  are  put  in  a 
pending  file  until  the  investigation  is  completed. 

Process   1.2.3 Produce  List  of  Received  Proposals. 

After  the  closing  date  is  over,  a  certain  program  in  the 
computer  is  triggered  to  match  the  RFP  Monitor  File  with  the 
Proposals  Monitor  File  and  produce  a  report  of  all  received 
proposals.  The  matching  key  is  the  RFP  Number  in  both  files. 
This  list  with  the  physical  copies  proposals  are  forwarded 
to  AA. 
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The   following   is   the   suggested   list   produced  by  the 
comput  er : 


PROPOSALS  LIST 


RFP 
NUMBER 


PROPOSAL 
NUMBER 


VENDOR 
NAME 


DATE 
RECEIVED 


TOTAL 
VALUE 


2 .   RFC  Function  Description 

The  potential  for  automation  of  this  function  is  not 
too  high  because  it  is  not  the  common  case  for  the  POW  to  do 
the  contracting  with  vendors,  except  for  small  contracts. 
This  function  has  high  potential  as  a  future  DSS  application 
for  evaluating  proposals  and  vendor  selection,  but  the 
volume  of  RFC  is  not  big  enough  in  POW  to  be  included  in 
thisthesis. 

The  manual  system  of  the  RFC  function  will  not  be 
changed,  except  recording  basic  RFC  data  to  produce  status 
reports.  Figure  4.7  shows  how  the  RFC  function. 

The  data  structure  of  the  RFC  is; 

*  RFC  Number   (Register  number) 

*  Date  Received 

*  RFP  Number 

*  Requester  (Force  or  Department) 

*  RFC  Subject 

*  Fund  Letter  Number 

*  Fund  Dollar  Amount 
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*  Vendor(s)  Best  and  Final  Offers 

*  Technical  Evaluation  Ranking 

*  Negotiation   Base   (Least   Cost   or  Price  Performance 
Ratio) 

3 .  Funding  Contracts 

The  funding  contract  function  is  also  small  because 
it  is  limited  only  to  commercial  contracts  signed  in  POW . 
Like  the  RFC  it  is  not  big  enough"to  be  automated.  For  chat 
reason  this  function  will  not  be  changed,  except  the 
management  of  the  guarantee  letters  of  all  contracts  signed 
withUS  vendors  either  in  Egypt  or  in  POW,  currently  about 
1500.  This  sub-  function  has  great  potential  for  automation 
because  the  Guarantee  Letters'must  be  monitored  by  POW.  This 
sub-  function  will  be  developed  as  a  part  of  the  Administer 
Contract  function. 

4 .  Administer  Open  Contracts 

By  developing  this  function  we  could  increase  the 
efficiency  of  POW.  The  basic  data  about  a  particular 
contract  must  be  recorded  in  the  Contract  Database  File 
(CDF).  The  data  structure  of  the  contracts  is: 

*  Department  Code   (2  Characters) 

*  Contract   Number     (Serial   number  within  department 
code  ) 

*  Contract  Name     (Heading  of  50  characters  ) 

*  Contract  Description  (TEXT  of  50  characters) 

*  Contact  Vendor  Name 
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*  Contract  Vendor  ID 

*  Contract  signed  date 

*  Contract  Total  Value 

*  Contact  Items    (Repetitive  group) 
»    Unit  of  Issue  UI 

*    Quantities 

*  Contract  Summary 

*  Inspection  Schedule 

*  Payment  Schedule 

*  Shipment  Schedule 

*  -Training  schedule 

*  Basic  Attached  document 

*  Guarantee  letters 

*  Source  of  fund  letter 

*  Case  designator  (for  the  loan  funded  contracts) 

*  Certificates 

The  following  are  the  sub-functions  to  be  automated: 

a .  Payment 

b.  Monitor  shipment 

c.  Monitor  Personnel  Training  related  to  contracts 

d.  Monitor  Guarantee  letters 

e.  Reporting 
a .   Payment 

The   contracts   are   sorted  into  groups  accordini 
to   the   specialized   area.    Each   specialized   officer   is 
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responsible  for  one  or  more  groups.  The  database  for  tiie 
contracts  must  be  centralized.  The  data  about  contracts  can 
be  retrieved  and  updated  through  the  computer  terminal.  The 
following  are  details  of  the  payment  process:  (Figure  4.8) 

Process   4.1.1 Register  the  Payment  Documents.  The 

payment  documents  are  received  and  registered  in  the  GLB 
then  routed  to  the  specialized  officer.  The  payment 
documents  consist  of  the  original  invoice,  the  shipment 
receipt  from  the  Freight  Forwarder  (FF),  and  the  certific- 
ates of  manufacture  and  warranty. 

Process    4.1.2 Review   and   Check   The   Payment 

Documents .  The  specialized  officer  accesses  the 
contract  database  and  contract  monitor  file  to  check  the 
documents  against  the  previous  payments,  shipment  schedule, 
etc.  to  be  sure  of  meeting  the  requirements  of  contract.  A 
pre-defined  report  may  be  produced  to  assist  him  in  doing 
his  job.   The  following  is  the  suggested  report  format: 


SHIPMENT  HISTORY 
CONTRACT     SHIPMENT     TOTAL 
NUMBER        NUMBER        VALUE 


DATE 
RECEIVED 


The  specialized  officer  can  also  retrieve  detail- 
ed information  about  a  particular  contract  or  vendor  to 
assist  him  in  making  his  decision  to  approve  the  payment. 

The  SO  will  be  authorized  to  record  the  data 
about    shipment   notice   and  the  certificates  related  to  his 
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contract   group   area.  The  following  is  the  data  structure  of 
the  shipment  notice; 

*  Contract  Number 

*  Shipment  Number 

*  Shipment  Date 

*  Shipment  Value 

*  Shipment  Items   (Repetitive  group) 

*  Name 

*  Unit  o-f  Issue 

*  Quantity 

*  Vendor  ID 

*  Shipment  data 

The   SO   approves   the   payment   and  forwards  C-he 
payment  documents  to  the  Financial  Officer  (FO). 

Process  ^.1.3  Check  The  Payment  Documents  By  The  FO 
.The  FO  checks  all  the  payment  documents  paying  special 
attention  to  the  validity  of  the  invoice.  He  will  be  able  to 
produce  reports  of  all  the  payment  information  about  a 
particular  contract  or  vendor.  He  can  also  produce  reports 
about  the  status  of  fund  availability.  The  following  is  the 
suggested  report  format: 


PAYMENT  HISTORY 


CONTRACT  INVOICE 
NUMBER   NUMBER. 


DATE 

RECEIVED 


TOTAL 
VALUE 
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The   FO  is  the  only  officer  authorized  to  record  the 
Invoice   information   in   the   computer   database.   The   data 
structure  of  the  invoice  is  as  follows: 

*  Invoice  Number 

*  Contract  Number 

*  Vendor  Code 

*  Date  Received 

*  Due  Date 

*  Total  Value 

*  Invoice  Items    (Option) 

*  Name 

*  Unitoflssue 

*  Quantity 

Process   4.1.4 Prepare   The   Payment  Check.  The  FO 

prepares  the  payment  checks  after  validation  of  all  payment 
documents  using  the  database  to  assist  him  in  making  his 
decision.  The  FO  records  the  checks  data  in  the  database 
after  getting  the  approval  of  payment  from  the  POW  director. 
The  following  is  the  data  structure  of  the  check: 

»    Check  Number 

*  Date  of  Issue 

*  Invoice  Number 
»    Bank 

»    Value 

*  Vendor  Company  Name 

*  Check  Contract  Number 
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b.   Monitor  Personnel  Training 

Process    4.2 Monitor    Personnel    Training. The 

personnel  training  sub-function  is  very  important.  Two 
processes  are  related  to  the  training:  preparation  and 
implementation  of  the  training  plan  and  following  up  of 
personnel  during  the  training  period  in  USA. 

Process   U . 2 .  1 Pepare  Training  Plan.  After  signing 

the  contract  the  training  information  is  extracted  from  the 
contract  and  recorded  in  training  database.  The  data 
structure  for  the  training  data  are: 

*  Contract  Number 

*  Line  number  related  to  training  in  the  the 
contract 

*  Number  of  personnel  to  be  trained 

*  Pre-request  for  training  (repetitive  group) 

*  Training  Period   (repetitive  group) 

*  Location(s)       (repetitive  group) 

*  Estimated    Date    of    training   (Repetitive 
group ) 

*  Actual  Date  of  Training 

Process   4.2.4 Personnel   Affair   in  training   The 

POW  becomes  responsible  for  all  officers  under  training 
along  the  period  of  staying  in  the  USA.  The  Administrative 
Officer  in  POW  is  responsible  for  preparing  the  monthly 
payment  for  all  officers,  mailing  them  the  checks  every 
month,  travel  reservations,  internal  transportation  during 
check  in/out  in  USA,  and  medical  care. 


I 
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4.3    Monitor  Shipment 
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Figure    4.9    Monitor  Shipment 
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The   following   is   the   suggested  data  structure 
personnel  monitoring  file: 

*  Person  Military  Number 

*  Rank 

*  Name 

*  Related  Force/Department 

*  Date  Arrived 

*  Date  Leave 

*  Training  Location 

*  Address 
City 
State 
Zipcode 
Phone  Number 

Point  of  Contact  in  the  Training  Center 
Home  Address  during  Staying  in  USA 

*  Addr  ess 
»    City 

*  State 

*  Z  ipcode 

*  Phone  number 
Contract  Number 
Course  Number 


for 
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*  Course  Description 

*  Training  Period 

*  Start  Date 

*  End  Date 

*  Monthly  payment  rate 

The  number  of  personnel  may  not  exceed  200  officers 
on  average  any  time  during  the  year.  The  automation  of  this 
function  is  not  included  in  this  thesis  because  of  the  time 
constraint.  '■ 

c.  Monitor  Shipment 

Process  4.3  Monitor  Shipment  of  Items  to  Egypt. 
The  Freight  forwarder  (FF)  is  contracted  to  do  this 
function.  The  POW  shipment  officer  has  an  access  terminal  to 
the  FF  computer.  No  potential  for  automation  is  recognized 
for  this  function.  The  manual  function  will  stay  without 
change  as  presented  in  chapter  II. 

d.  Monitor  Guarantee  Letters 

Process  4.4  Monitor  Guarantee  Letters.  The  total 
number  of  active  guarantee  letters  may  exceed  1000  with  a 
total  value  over  $10  million.  Keeping  track  of  these  letters 
is  very  important.  The  proposed  system  is  a  warning  system 
to  prevent  losing  the  guarantee  letters  after  they  exceed 
their  validity  periods.  The  software  requirement  for  this 
function  is  simple.  All  the  Guarantee  letters  are  recorded 
in  a  database  file.  A  printed  list  is  produce  every  week  of 
the   guarantee   letters   that   need   to  be  renewed.  This  list 
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Figure  4.10  Monitor  Personnel  Training 
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is  produced  far  enough  ahead  to  allow  enough  time  for 
requesting  the  renewal.  The  data  structure  for  the  guarantee 
letters  is: 

*  Contract  Number 

*  Guarantee   Letter  number  (within  the  Contract 
number ) 

*  Bank  issued  from 

*  Vendor  ID 

*  Vendor  Name 
»    Total  Value 

*    The  purpose  of  the  guarantee  letter 

*  Starting  Date  of  Validity 

*  Ending  Date  of  Validity 
e .    Reporting 

Process  4,5  Prepare  Reports.  The  reporting 
facility  of  the  PC/FOCUS  database  is  very  powerful  and  can 
be  used  to  generate  any  reports  needed  by  POW.  In  chapter  II 
we  presented  only  the  general  kinds  of  reports  that  may  be 
produced.  In  this  Chapter,  we  inroduce  specific  reports  to 
be  generated.  It  is  not  necessary  that  all  reports  be 
printed;  most  of  them  may  be  needed  only  as  a  screen 
displays.  PC/FOCUS  has  the  facility  to  view  the  report  on 
the  screen  first.  If  the  user  needs  to  print  it,  he  can  then 
issue  two  commands:  OFFLINE  to  let  PC/FOCUS  forward  the 
output  to  the  printer  and  RETYPE  to  repeat  the  document. 
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The  following  are  a  list  of  the  proposed  reports: 
( 1 )  The  status  Reports; 

-  Vendor  Status  Report 
RFP/Proposals  Report 

-  Depar tmen t / RF P  Report 

-  Department / Con  tract 

-  Vendor  /  Contract  Report 
Department  /  Vendor 

-  Vendor  /  Department 
( 2  )  Progress  Reports; 

-  Contract   implementation  over  a  period  of  time  by 
the  value  received. 

Shipment  of  items  over  a  period  of  time 

-  RFP  Received  and  processed  during  a  period 
(3)  Comparison  reports; 

These  kind  of  reports  are  very  important  for 
decision  support.  Mainly  it  can  be  used  during 
evaluation  functions.  The  financial  modeling 
function  of  PC/FOCUS  can  be  used  to  produce 
these  kind  of  reports.  The  graphic  terminal 
system  may  be  used  for  the  graphic  presentation 
of  these  reports. 
5 .   Generate  Effective  Vendor  Database 

We  need  to  build  an  effective  vendor  database  for 
the  potencial  and  qualified  vendors  who  are  most  suitable  to 
be   supplier  for  the  Egptian  Armed  Forces.  This  function  has 
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a  highly  payoff  compared  with  the  other  functions  because 
it's  relatively  simple  to  implement  on  the  computer  and  a 
great  effort  is  needed  in  the  manual  system  to  prepare  tne 
vendor  list  for  a  particular  RFP.  It  may  take  more  than  a 
week  to  prepare  a  vendor  list  for  a  particular  RFP. 

In  the  USA  there  are  over  1j5,000  manufacturers.  Je 
cannot  practically  put  all  the  qualified  vendors  in  USA  in 
our  database,  otherwise  it  becomes  very  big.  The  practical 
approach  to  building  an  effective  vendor  Ddtabase  for  POW  is 
to  include  initially  only  vendors  who  already  have  contracts 
with  POW.  We  can  then  add  the  RFP-  driven  vendors  to  it  i.e. 
all  vendors  who  offer  accepted  proposals.  Periodically,  the 
vendor  database  is  reviewed  and  non-active  vendors  are 
dropped.  Other  sources  of  potential  vendors  may  be  used  such 
as:  USA  Armed  Forces  and  Government  suppliers,  and  Thomas 
Register . 

The  following  is  the  data  structure  for  a  specific 
vendor: 

*  Vendor   ID   (A   local   code  is  used  with  a  cross- 

reference  table  for  vendor  code) 

*  Vendor  Name 

*  Vendor  Point  of  Contact 

*  Vendor  Address 
»    Street 

»    City 
*    state 
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*  Zip    code 

*  Phone  Number 

*  Telex 

*  Business  Asset  Rate 

*  Business  Start  Date 

*  Business  Activities   (Repetitive  group) 

*  Vendor  Item  Classes   (Repetitive  group) 

*  Vendor  Department  Area 

*  Vendor  Supplier  to  USA  Armed  Forces 

*  Vendor  Previous  Relation  with  POW 

*  Vendor  Rating  Grade 

C.   CONCLUSION  OF  THE  CHAPTER 

This  chapter  was  very  important  because  all  the 
necessary  information  to  build  the  new  system  are  now 
available.  Each  function  is  analyzed  to  determine  whether  or 
not  be  automated,  The  data  elements  for  each  function  is 
determined  also,  the  revisited  DFD's  are  used  to  explain  the 
system.  The  data  dictionary  section  is  moved  to  the  next 
chapter  to  integrate  it  with  the  design  issues  for  the  new 
system.  Figure  4.11  shows  the  logical  relations  between  the 
Entities  of  the  system,  the  lines  with  arrows  represent  a 
one  to  many  relationship  between  the  entities.  In  the 
designed  system  an  entity  may  be  divided  into  one  or  in  ore 
database  file. 
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V.  SOFTWARE  DESIGN  OF  POWCP  SYSTEM 

A.   OBJECTIVES 

DSS  consists  of  three  major  components,  a  data  base,  a 
model  base,  and  a  dialog  components.  The  objective  of  the 
software  design  is  to  build  the  data  base  components,  the 
most  important  components  in  DSS. 


The  DBMS  is  one  of  the  three  major  components  of  a  DSS. 
(The  other  two  components  are  the  dialog  component  and 
the  model  component.)  A  DBMS  is  an  important  tool  for 
building  a  DSS,  and  a  poor  data  base  management 
.component  can  cause  the  failure  of  a  DSS.   LRef.  1] 

The   software   we   use   is  the  PC/FOCUS  which  allows  easy 

building   of   the   other   two   components  as  well.  The   POWCP 

system  attempts  to  aim  at: 

1.  Improving  the  performance  of  POW  in  the  Commercial 
Procurement  system  by  providing  the  right  inform- 
ation at  the  right  time  to  the  right  person.  The 
result  of  the  system  must  affect  the  RFP  function  by 
reducing  the  time  for  preparing  the  list  of  vendors 
who  are  qualified  to  receive  a  particular  RFP  and 
improving  the  capability  of  POW  to  administer  the 
open  contracts. 

2.  Introducing  automated  assistance  to  im^prove  decision 
making  in  POW . 

B.  DATABASE  STRUCTURE 

1,   Database  File  Relation 

The   following   are   the  database  file  relations  that 

show   the   primary   key   fields   in   each   file   "underlined" 

and   the   other  fields  which  are  used  for  linking  the  file  in 

the  database. 
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POWDEP(REQj-ID,      .  .  .  ) 

POWRFP(RFP-NQ),DEP-ID,      ...) 

POWRFCC RFC-NO, RFP-NQ, DEPART-NO  1,   ...) 

POWVNDR  (VEND£R-I_D  .DEPCUSTOMER  ,  ...) 

PQWCQNTR(CQNTR-NO,CQNTRACT-DEP,CONTRACT-VID,  . . . ) 

PQWBANKC  BANK-NO ,  ...) 

POWINVQI(INVOICE-NQ, INV-CONT-NO,INV-VNDR-ID,INV-CHECK-NO, 
.  .  .  ) 

PQWQRDR(PAYQRDER-NO , PAY-0-INV-NO,PAY-ORD-BANK,  ...) 

PQWCHECKC CHECK-NO, CHECK-INV-NO , CHECK-BANK,   ...) 

P0WICLAS(VEND0R-ID1,VNDR-ITEM-C,  ...) 

P0WVDEP(VEND0R-ID2,VNDR-DEP-N0,  ...) 

POWSHIPN(SHIP-NOTICE,SHIP-CONT-NO, SHIP-INV-NO,  ...) 

POWCITEM(CONTR-NO  1  , ITEM-CODE,  ...) 

POWBNKACC BANK-NO , BANK- AC  CO U NT ,  .  .  .  ) 

2.   Database  Schema 

Figure  5.1  shows  the  relations  between  the  database 
files.  Notice  that  the  first  five  files  represent  the 
commercial  procurement  cycle  until  signing  of  the  contract. 
The  rest  of  the  files  represent  the  administration  contract 
function.  The  connection  between  the  two  groups  is  done  via 
the  contract  file.  This  structure  provides  the  most  simple 
way  of  building  the  database.  The  key  fields  are  underlined 
and  the  other  fields  are  used  to  connect  the  different  files 
which   can   be   done  easily  by  the  join  facility  of  PC/FOCUS. 
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From   this   structure   we   can   generate   many  of  the  logical 
structure  to  produce  the  required  reports. 

C.   DESIGN  IMPLEMENTATION  ISSUES 
1 .   Data  Dictionar  y 
a.   Normalization 

Since  we  are  going  to  build  the  DSS  generator  of 
POWCP  system,  the  database,  normalization  of  data  is  very 
important  as  a  necessary  logical  step  before  undertaking  the 
physical  design  of  the  database.  One  of  the  objectives  of 
normalization  is  to  get  the  simplest  possible  representation 
of  data  that  we  can  get.  In  other  words,  remove  the  complex 
relationships  between  data  structures  by  removing  repeating 
groups  (first  Normal  Form  (INF)),  group  all  nonkey  data 
elements  in  a  structure  to  be  fully  functionally  dependent 
on  a  single  primary  key  in  the  same  structure  (Second  Normal 
Form  (2NF)),  and  remove  all  the  nonkey  data  elements  which 
are  functionally  dependent  on  other  nonkey  data  element  in 
the  same  structure  (Third  Normal  Form  (3NF)).  The  reasons  to 
do  data  normalization  before  designing  the  physical 
database  are:  a.  Construct  the  simplest  possible  data 
structure  before  loading  the  database  because  it  is 
difficult  to  change  the  structure  of  the  database  after 
loading  the  actual  data  to  the  system  (although  PC/FOCUS 
allows  data  base  rebuilding  via  the  REBUILD  COMMAND  which 
allows    reorganizing,   reindexing,   and   rebuilding   damaged 
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FOCUS   files);   b.   Normalization  prevents  deletion  anomalies 

which   means  that  we  may  lose  facts  about  two  entities  by  one 

deletion.   For   example   if  the  item  class  only  exists  in  the 

vendor   record,   if   only  one  vendor  supplies  this  item  class 

and   this   vendor   does   not   exist  in  our  database,  the  item 

class   also   will   not   exist.   Normalization   also   prevents 

insertion   anomalies   which   constrains   inserting   an  entity 

unless  another  logically  unrelated  entity  is  also  inserted. 

Both  for  the  manual  and  for  computer  systems,  it  usually 
is  easier  and  cheaper  to  change  the  logic  of  a  process 
than  to  change  the  structure  of  a  data  store. 
Consequently,  the  simpler  and  more  general  the  structure 
of  a  data  store,  the  easier  and  cheaper  it  will  tend  to 
be  to  make  changes  in  the  data.   [Ref.  3] 

b.   RFP  Structure  Normalization   (An  Example) 

The   Request   For   Proposals  (RFP)  data  structure 

will   be   used   as   an   example   to   apply   the  normalization 

technique.   For   the   other   data   structures,  we  present  the 

final   result   in  3NF  with  the  proper  names  that  will  be  used 

in  the  physical  design  of  the  database. 
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(Force  or  Department) 
(Two  character  code) 

(Repetitive  group) 


RFP  Data  Structure;       (Not  normalized) 
RFP  Number 

-  Date  Received 

-  Requester  Code 

-  Requester  Name 
RFP  Subject 

-  Items  Needed 

-  Item  Name 

-  Unit  of  Issue 
Quantity 

*  -    Items  Class       (key   words   such  as;  Tools, 

Engines, Pumps,     Computers, 
etc  .  ) 

-  Estimated  Dollars 

-  Source  of  Funds   (Budget,  Loans,  Others) 

*  -    Suggested  Vendor  Names    (Repetitive  group) 
The   data   marked   with  "*"  are  repeating  groups. 

The  data  elements  marked  by  "+"  are  not  functionally 
dependent  on  the  RFP  number.  No  data  elements  functionally 
dependent  on  other  data  elements  appear  in  the  RFP  data 
structure.  To  do  the  normalization,  first  we  separate  the 
repeating  groups  as  follows; 
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RFP  Data  Structure 
RFP  Number 

-    Date  Received 
Requester  Code 
Requester  Name 

RFP  Subject 


(  1  NF) 
(Key  data  element) 


Estimated  Dollars 
Fund  Source 


RFP  Number 
Items  Needed 
Item  Name 
Unit  of  Issue 
Quant  i  ty 

RFP  Number 
Item  Classes 


RFP  Number 


Sugg.  Vendor  tJame 
Second,    we  separate  the  data  elements  marked  by 
"+"   and   leave   the   Requester   Code   to   link   the  two  data 
structures   as   needed.    The  following  is  the  data  structure 
in  2NF: 


1  14 


RFP  Data  Structure 

RFP  Number. 

-  Date  Received 

-  Requester  Code 


(2NF) 

(Key  data  element) 


Requester  Code 
Requester  Name 


RFP  Subject 


Estimated  Dollars 
Fund  Source 


RFP  Number 
I  terns  Needed 
I  tern  Name 
Unit  of  Issue 
Quantity 
RFP  Number 
Item  Classes 


RFP  Number 


Sugg.  Vendor  Name 
The  above  structure  is  in  third  normal  form.  We 
notice  that  the  original  RFP  data  structure  is  divided 
physically  into  six  normalized  data  structures.  These 
structures  can  be  logically  grouped  together  to  form  the 
original  data  structure  or  any  other  structure  as  required. 
In  the  following  page  the  new  six  data  structure  are 
presented . 
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PQWRFP  FILE; 

*RFP_NG 

RFP_DATE 
+REQ_ID 
RFP_SUBJECT 
RFP_COMMENT 

PQWREQ  FILE; 

»REQ-CODE 
REQ-NAME 

RFPITEM  FILE; 

+RFP_N01 

+ITEM_CODE 

UNIT_OF_ISSU 

QUANTITY 


RFPICLAS  FILE 


ITEMCLAS    FILE 


+RFP_NO 
+ITEM  CLASS 


»ITEM_CLASS 
SPECFICATION 


SUGVNDR  FILE; 
+RFP_NO 
+VENDOR  ID 
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The  new  structure  of  the  RFP  data  structure  is  divided 
into  six  files  which  are  in  the  3NF  an-d  prevent  deletion  or 
insertion  anomalies  as  we  can  see  from  the  RFPICLAS  and 
ITEMCLAS  files.  We  notice  that  the  key  fields  are  identified 
by  "*"  which  means  only  one  occurrence  is  allowable  for  each 
value  of  a  key.  These  fields  must  be  indexed  to  allow  joins 
between  other  records  of  the  same  values  in  PC/FOCUS.  The 
fields  identified  by  "+"  means  that  these  fields  can  be  used 
for  joins  between  records.  Combining  two  fields  of  type  "+" 
form  a  key  of  type  "*"  which  uniquely  identifies  one 
occurrence  of  a  record. 

c.   File  Structure 

The  following  are  the  database  record  descrip- 
tions which  are  produced  using  the  PC/FOCUS  Filetalk 
utility.  The  Filetalk  utility  allows  the  user  to 
interactively  create  Master  File  Descriptions  (MFD).  All 
MFD's  are  described  as  a  single  record  (segment).  Each 
record  contains  a  group  of  relevant  data.  Notice  that  every 
name  of  a  record  is  preceded  by  the  procurement  office 
initials,  POW,  to  allow  easy  recognition  of  the  files  and 
prevent  it  from  accidental  deletion.  N'ote  that  the  key  field 
of  each  record  is  marked  by  "*"  at  the  beginning  of  the 
line.  The  other  key  fields  which  may  used  for  joining  the 
files  are  underlined. 
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FILENAME=POWDEP,SUFFIX=FOC 


(Force  or  Department  File) 


SEGNAME=0NE,SEGTYPE=S1 
»FIELDNAME=DEPARTID ,     ALIAS=DEP, 


F0RMAT  =  A2,FIELDTYPE  =  I,cp 


FiELDNAMErDEPART  NAME,   ALIAS=DEPN,   F0RMAT=A25, 


FILENAME=PQWRFP,SUFFIX=FOC 
SEGNAME=0NE,SEGTYPE=S1 
»FIELDNAME=RFP  NO, 


(Request  For  Proposals) 


ALIAS=RFPN,  FGRMAT=I6,FIELDTYPE=I,$ 


FIELDNAME=RFP_DATE, 

FIELDNAME=DEP  ID, 

FIELDNAMErRFP  SUBJECT,   ALIAS=SUBJ,   F0RMAT=A50, 


ALIAS=RFPD,   F0RMAT=I6MDY, 
ALIAS=DEPC,   F0RMAT=A2, 


FIELDNAME=N_OF_VENDORS,  ALIAS=NOV, 
FIELDNAME=NOF_PROPOSAL,  ALIAS=NOP, 
FIELDNAMErRFP  COMMENTS,  ALIAS=, 


F0RMAT=I2, 
F0RMAT  =  I2  , 
F0RMAT=A50 , 


FILENAME=POWRFC,SUFFIX=FOC 

SEGNAME=0NE,SEGTYPE=S1 
*FIELDNAME=RFC  NO, 
FIELDNAME=RFC_DATE , 
FIELDNAME=RFP  NQ1, 
FiELDNAMErDEPART  NOT, 


(Request  For  Contracting) 


ALIASrRFCN,   F0RMAT=I6,FIELDTYPE=I,$ 


ALIAS=RFCD,   FORM AT = I 6M DY , 
ALIAS=RFPN1,  F0RMAT=I6, 
ALIASrDEPNI,  F0RMAT=A2, 


FIELDNAME=RFC_SUBJECT,  ALIAS=RFCS,   FORMAT=A50, 

FIELDNAME=FUND_LETTER ,  ALIAS=FLN,     FORMAT=AjO, 

FIELDNAME=FUND_AMMOUNT,  ALIAS=FAM0UNT,F0RMAT=D12.2M, 

FIELDNAME=RFC  COMMENT,  ALI AS = RFCCOM , FORM AT = A5 0 , 
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FILENAME=POWVNDR,SUFFIX=FOC 


(Vendor  File) 


ScGNAM£=ONE,SEGTYPE=Sl 
»FIELDNAME=VENDOR  ID, 


ALIA3=VC0DE,  F0RMAT=I4,FIELDTYP£=I,$ 


FIELDNAME=THOMAS_VOL_N,  ALIAS=THVN,  F0RMAT=I2, 

FIELDNAME=THOMAS_PAG_N,  ALIAS=THPN,  F0RMAT=I3, 

FIELDNAME=VENDOR_NAME,  ALIAS=VNAME,  FORMAT=A50, 

FIELDNAME=POF_CONTACT,  ALIAS=POFC,  FORMAT=A25, 

FIELDNAME=VENDOR_ADRES,  ALIAS=VADRS,  FORMAT=A25, 

FIELDNAME=VENDOR_CITY,  ALIAS=VCTY,  F0RMAT=A15, 

FIELDNAME=VEND0R_3TATE ,  ALIAS=VSTA,  F0RMAT=A4, 

FIELDNAME=VENDOR_ZIPC,  ALIAS=VZIPC,  F0RMAT=I7, 

FIELDNAME=VENDOR_?HONE ,  ALIAS=VPH,  F0RMAT=A14, 

FIELDNAME=VENDOR_TEL£X,  ALIAS=VTLX,  F0RMAT=A12, 

FIELDNAME=VENDOR_ASSET ,  ALIAS=VASS,  F0RMAT=A6, 

FIELDNAME=VENDOR_START ,  ALIAS=VSTD,  F0RMAT=A4, 

FIELDNAME=V_ACTIVITIES,  ALIAS=VAC,  FORMAT=A50, 

FIELDNAMErDEP  CUSTOMER,  ALIAS=DEPC,  F0RMAT=A2, 


FILENAME=PQWCONTR,SUFFIX=FQC      (Contract  File) 
SEGNAME=0NE,SEGTYPE=S1 

*FIELDNAME  =  CGNTRACT  NO,  ALIAS  =  CN,      FO RM AT  =  I  5 , F I ELDT YP E = 1 , $ 
FIELDNAME=CONTRACT  NAM,  ALIAS=CNAM,   FORMAT=A50,  $ 


FIELDNAME=CONTRACT_DES,  ALIAS=CDES,  FORMAT=A50, 

FIELDNAME=CQNTRACT  PEP,  ALIAS=CDEP,  F0RMAT=A2, 

FIELDNAMErCONTRACT  VIP,  ALIAS=CVIP,  FGRMAT=IU, 

FIELPN'AME  =  C0NTRACT  pat,  ALIAS  =  CPATE,  F0RMAT  =  I6MDY  , 
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FIELDNAME=CONT_VALUE,     ALIAS=CVALUE,F0RMAT=D14.2, 
FIELDNAME=CONT  COMM,      ALIAS=CCOMM,  FORMAT=A50, 


FILENAME=POWBANK,SUFFIX=FOC 


( Bank  File ) 


SEGNAME=0NE,SEGTYPE=S1 
*FIELDNAME=BANK  NO, 
FIELDNAMErBANK  NAME, 


ALIAS=BNO,    F0RMAT=I2,FIELDTYPE=I,$ 
ALIAS=BNAME,  FORMAT=A20,  $ 


FIELDNAMErBANK  ADDRES,   AL I  AS  =  B AD  RES , FORM AT  =  A25  , 


FIELDNAME=BANK_CITY, 
FIELDNAME=BANK_STATE, 
FIELDNAME=BANK_ZIPC, 
FIELDNAME=BANK_PHONE , 
FIELDNAMErBANK  TELEX, 


ALIAS=BCTY,   FORMAT=A25, 
ALIAS=BSTATE,F0RMAT=A4, 
ALIAS=BZIPC,  F0RMAT=I7, 
ALIAS=BPH0NE,F0RMAT=A14, 
ALIAS=BTLX,   F0RMAT=A14, 


FILENAMES PQW IN vol ,SUFFIX=FOC  (Invoice  File) 

SEGNAME=0NE,SEGTYPE=S1 

»FIELDNAME=INVOICENO ,   ALIAS  =  INVN,   FO RM AT  =  I  6 , F I ELDT YP E  =  I , $ 


FIELDNAME=INV  CQNT  NO,  ALIAS=INVCN,  F0RMAT=I6, 

FIELDNAME=INVOICE_SUBJ ,  ALIAS=INVSUBJ,FORMAT=A50, 

FIELDNAME=INV_VENDR_ID,  ALIAS=INVVID,F0RMAT=I4, 

FIELDNAME=INVOICE_DATE,  ALIAS=INVD,   FORM AT = I 6M DY , 

FIELDNAME=INVOICE_VALU ,  ALIAS=IVLU,   FO RM AT = D 1 2 . 2M , 

FIELDNAME=INV_DUE_DATE ,  ALIAS=IDUE,   FORM AT = I 6M D Y , 

FIELDNAME=INV  CHECK  NO,  ALIAS=ICHKN0,F0RMAT=I8, 

FIELDNAME=INV_PAY_DATE ,  ALIAS=IPD,     FORM AT = I 6MDY , 

FIELDNAMErlNV  COMM,  ALIAS=,        FORMAT=A50, 
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FILENAME=POWORDER,SUFFIX=FQC  (Pay  Order  File) 

SEGNAME=0NE,S£GTYPE=S1 

*FIELDNAME=PAY  ORDER  NO,ALIAS  =  PQN  ,     F0RMAT=I8,FIELDTYP£=I,$ 


FIELDNAME=PAY_ORDR_DAT ,  ALIAS=POD,     FORM AT = I 6MD Y , 

FIELDNAME=PAY  0  INV  NO,  ALIAS=P0INVN,F0RMAT=I6, 

FIELDNAMErPAY  ORD  BANK,  ALIAS=POB,     F0RMAT=I2, 

FIELDNAME=PAY_0_VALUE ,  ALIAS=POV,     FORM AT= D 1 2 . 2M , 

FIELDNAME=PAY  0  VIP,  ALIAS=POVID,  F0RMAT=I4, 

FIELDNAME  =  PAY  TOV/HOM,  ALIAS  =  P0T0,   F0RMAT  =  A25, 


FILENAME=POWICLAS,SUFFIX=FOC 
SEGNAME=ONE ,SEGTYPE=S1 
»FIELDNAME=VENDOR  ID1,   ALIAS=VID1, 
FIELDNAME=VNDR  ITEM  C,   ALIAS=VIC, 


(Items  Class  File) 

F0RMAT=I4, 
F0RMAT=A15, 


FILENAMErPOWVDEP, SUFFIX=F0C 
SEGNAME=0NE ,SEGTYPE=S1 

*FIELDNAME  =  y_EN_D0R_I_D2,   ALIAS  =  VC0DE2,F0RMAT  =  I4, 
FIELDNAME=VNDR  DEP  NO,   ALIAS=,        F0RMAT=A2, 


(Vendor  Department  File) 


FILENAME=POWSHIPN , SUFFIX=FOC 
SEGNAME=0NE,SEGTYPE=S1 
*FIELDNAME=SHIP  NOTICE,  ALIAS=SHN, 
FIELDNAME=SHIP  CONT  NO,  ALIAS=SHCN, 


(Snipment  Notice  File) 

F0RMAT=I6,FIELDTYPE=I,$ 
F0RMAT=IU,  $ 
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FIELDNAME=SHIP_SUBJECT,  ALIAS=SHS,     F0RMAT=A50, 
FIELDNAME=SHIP  INV  NO,   ALIAS=SHIN,   F0RMAT=I6, 
FIELDNAMErSHIP  DATE,      ALIAS=SHD,     FORM AT = I 6M DY , 


F0RMAT=I6, 
F0RMAT=A12 


FILENAME=POWCITEM,SUFFIX=FQC  Contract  Item  File 

SEGNAME=0NE,SEGTYPE=S1 
*FIELDNAME  =  CONTRACT  NQ1,ALIAS  =  CN1  , 
FIELDNAMErlTEMD  CODE,     ALIAS=ICOD 

FIELDNAME=ITEM_DESCRP    ALIAS=IDESC   FORMAT=A30 
FIELDNAME=UNIT-OF-ISSUE  ALIAS-UI       F0RMAT=A2 
FIELDNAME=CONT_QTY       ALIAS=CI,  •    F0RMAT=A30,  3 

FILENAME=PQWBNKAC,SUFFIX=FQC 
SEGNAME=0NE,SEGTYPE=S1 

*FIELDNAME  =  BANK  NUMBER,  ALIAS  =  BID1,   FO  RM  AT  =  I  2  ,  F  I  E  LDT  YP  E  =  I  ,  :p 
FIELDNAMErBANK  ACCOUNT,  ALIAS=BACC,   FORMAT=A10,  $ 

2.   Using  PC/FOCUS  for  the  POW  Softeware 

The  purpose  of  this  section  is  to  justify  i;he  use  of 
PC/FOCUS  as  a  DSS  generator  for  the  POW  system.  Some  of  the 
most  important  and  useful  features  of  PC/FOCUi  are 
highlighted  below. 

a.   Files  Description 

PC/FOCUS  supports  a  hierarchical  model,  i.e.  the 
file  description  allows  a  one  to  many  relationship  between 
segments  (records)  in  FOCUS  file  or  the  parent  to  many  child 
segments.  The  data  description  language  of  PC/FOCUS  allows 
free   format   delimited   by   ^   to   signify  the  end  of  single 
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description.  A  checking  procedure  can  be  used  to  check 
errors  in  the  file  description.  After  data  entry,  changes  in 
the  file  description  are  not  allowed  unless  they  are  a  part 
of  reorganization  of  the  physical  database.  (Rebuild 
facility  of  PC/FOCUS  allows  down  loading  an  "old "physical 
data  base  to  a  "new"  description  carefully  made  by  the 
designer.  File  relationships  (cross-reference  of  files  )  in 
the  database  can  be  made  static  through  FOCUS  file 
description  as  a  parent  child  relation  or  dynamic  using 
PC/FOCUS  JOIN  command  which  can  be  invoked  when  needed  to 
link  two  entire  file  structures.  The  condition  for  using  the 
JOIN  command  is  to  allow  at  least  one  field  in  the  desired 
segment  of  each  file  to  be  of  type  "indexed"  in  the  file 
description.  Any  number  of  fields  may  be  indexed  on  a 
segment.  PC/FOCUS  FileTalk  also  allows  easy  checking  of  file 
descriptions  by  producing  a  graphical  representation  of 
files  and  segment  relations. 

b.   Data  Manipulation  in  PC/FOCUS 

A  non-procedural  language  is  used  for  data 
manipulation  and  producing  reports  from  the  database.  Two 
functional  types  of  manipulation  language  are  available  in 
PC/FOCUS:  the  transaction  processor  and  the  dialogue 
manager . 

( 1 )  The  Transaction  Processor .  is  used  for 
report  preparation  by  invoking  the  MODIFY  command  and  typing 
an   imperative   English   statement   consisting  of  one  or  more 
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verbs  followed  by  verb  objects  and  optionally  by  various 
other  phrases.  All  these  statement  follow  'the  general  rules 
of  English  grammar.  The  request  statement  contains  all 
information  the  user  has  to  provide  in  order  to  retrieve  the 
desired  records,  perform  any  calculations,  sort  lines, 
accumulate  totals,  etc.  Information  which  is  not  provided 
explicitly  by  user  will  be  supplied  by  FOCUS  as  default 
options.  The  transaction  processor  has  a  facility  to  create 
screens  for  f i 11-in- the-b lank  data  entry  called  FIXFORM.  The 
MATCH  subcommand  is  used  to  designate  fields  to  match. 
Logical  subcommands  are  used  to  process  any  demands  from  the 
database.  It  is  possible  to  store  FOCUS  transaction 
processing  routines  in  a  command  file  for  later  use. 

(2)  The  Dialogue  Manager.  is  a  stored 
procedure  that  '  may  contain  variable  information  for  which  a 
value  is  provided  only  at  the  time  of  execution.  The 
variables  can  be  used  to  represent  numeric  constants,  dates, 
or  to  conduct  a  dialogue  by  prompting  the  user  for  a 
response.  The  Dialogue  Manager  is  invoked  by  typing  the 
FOCUS  command  "EXEC"  or  "EX"  followed  by  the  name  of  the 
procedure  . 

c.   Built-in  Facilities  in  PC/FOCUS 

In  addition  to  file  description  and  data 
manipulation,  there  are  many  important  facilities  that  make 
using  PC/FOCUS  database  atractive  for  our  system.  The 
following  are  the  summary  of  each  facility  as  presented  in 
[Ref  .  8  J 
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(1)  Describing  External  Files.  The  report 
request  language  can  be  used  on  data  files  that  are  not 
maintained  by  FOCUS  and,  hence,  are  external.  These  are 
existing  files  which  are  maintained  by,  or  extracted  from, 
other  systems . 

(2)  Maintaining  FOCUS  database.  A  simple 
language  is  used  to  control  all  the  processes  of  adding  new 
records  to  FOCUS  database,  deleting  records, and  changing 
values  in  existing  records.  Coupled  with  a  transaction 
validation,  computational,  and  logging  facilities,  the 
result  is  surprisingly  brief  set  of  ideas  that  must  be 
learned  in  order  to  maintain  FOCUS  database. 

( 3 )  SCAN  -  Interactive  Editing  Facility .  The 
SCAN  facility  is  designed  to  take  advantage  of  an  inter- 
active environment.  It  allows  a  user  to  'browse'  through  a 
FOCUS  file  of  any  size  by  issuing  one-line  commands  such  as 
TYPE,  NEXT,  REPLACE,  ETC.  and  receive  an  immediate  response 
before  issuing  the  next  command.  Users  familiar  with  a  text 
editor  will  find  the  similarities  useful  in  learning  SCAN. 

(4)  ANALYSIS  -  Formal  Statistical  Analysis, 
normal  statistical  techniques  such  as  multiple  regression, 
step-wise  regression,  and  correlation  analysis  are  performed 
on  data  in  FOCUS  (or  external)  files.  Control  over  the 
techniques  is  exercised  in  an  interactive  dialogue.  The 
displays  include  all  of  the  formal  statistical  quantities. 
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(5)  GRAPHS .  The  report  request  language  is 
used  to  phrase  and  control  graphical  displays  such  as  point 
plots,  bar  charts,  histograms  and  scatter  diagrams.  Normal 
terminal  output  or  high  resolution  graphics  can  be  prepared. 
Default  values  are  used  for  widths,  grid  values,  etc.  to 
simplify  the  process,  but  user  can  specify  precise  values 
when  customized  plots  are  needed. 

(6)  User  Defined  Language.  Users  can  change 
the  language  and  vocabulary  of  FOCUS  to  suit  their  own  needs 
and  preferences. 

(7)  Financial  Modeling  Language.  The  report 
request  language  has  a  series  of  features  designed 
specifically  for  the  preparation  of  'row  oriented'  reports. 
These  arise  frequently  in  financial  applications  where 
reports  such  as  Balance  Sheets  and  Cash  Flow  statements  are 
needed .  f 

(8 )  FIDEL-FOCUS  Interactive  Data  Entry  Language 
FIDEL  enables  the  design  and  implementation  of  full  screen 
interactive  data  entry  systems  as  part  of  the  data 
maintenance  facility.  It  also  provides  easy  development  of 
'menu'  selection  processes. 

3 .   Database  Creation 
a .   Data  Entry 

The  Automode  utility  is  used  to  enter  data  in 
the  database.  Test  data  have  been  generated  to  load  the 
database.  Real  data  will  be  loaded  during  the  implementation 
phase  . 
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b.  Validation 

PC/FOCUS  allows  validation  of  data  during  data 
entry.  A  record  is  rejected  if  any  violation  of  field  format 
occurs  or  if  a  record  with  the  same  key  field  is  entered 
twice.  In  the  latter  case  the  last  one  entered  will  be 
rejected  by  PC/FOCUS.  Automode  does  not  allow  range 
validation.  There  is  a  very  powerful  tool  for  interactive 
data  entry,  FOCUS  INTERACTIVE  DATA  ENTRY  LANGUAGE  (FIDEL)) 
FIDEL  allows  the  user  to  enter  data  through  a  visual  'fill 
in  the  form'  method.  After  each  successful  transaction,  the 
data  portions  of  the  screen  are  blanked  out,  leaving  only 
the  mask.  If  an  error  is  discovered  in  the  transaction  an 
error  message  will  appear  on  the  bottom  of  the  screen.  A 
bell  will  ring  (if  the  CRT  is  so  equipped)  and  the  screen 
will  not  blanked  out,  thus  giving  the  operator  a  chance  to 
correct  the  error  and  retransmit  the  screen.  The  FIDEL 
provides  validation  and  protection  mechanisms  during 
interactive  data  entry.  The  complete  language  rules  and 
facilities  are  presented  in  the  PC/FOCUS  user  manual  [Ref. 
8J.  In  this  thesis  we  are  not  going  to  use  this  tool 
because  of  the  time  limitation  for  the  thesis.  Automode 
provides  adequate  facility  for  data  entry  in  this  prototype. 

c .  Security 

One   problem   with   using   the   computer   is   the 
possibility   of   losing  data.  An  important  step  in  developing 
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any  computer  system  is  instituting  procedures  for  backup  of 
the  actual  data  in  the  database  and  for  prevention  of 
unauthorized  access  to  data.  In  our  system,  the  security 
procedure  is  simple.  FOCUS  files  containing  data  have  cin 
extension  xxx.FOC  to  distinguish  them  from  other  files.  The 
prefix,  POW  is  used  to  precede  all  files  generated  by  the 
system.  Only  an  authorized  person  is  allowed  to  delete  these 
files.  Every  week  a  backup  for  all  files  in  the  database  is 
done  on  floppy  diskettes.  Data  entry  and  updating  is 
limited  to  authorized  persons  only.  PC/FOCUS  has  powerful 
tools  for  security  which  can  be  used  for  later  development 
of.thesystem. 

d.   Database  Size 

The   following   table   shows   the   length   of  the 
different  database  files: 
FILE  NAME      LENGTH     ORGANIZATION      NO  OF  RECORDS 


POWDEP 

27 

Indexed 

20 

POWVNDR 

223 

Indexed 

500 

POWICLAS 

34 

200 

POWVDEP 

6 

1000 

POWRFP 

1  18 

Indexed 

800 

POWRFC 

162 

Indexed 

150 

POWCONTR 

182 

Indexed 

600 

POWCITEM 

36 

3000 

POWINV 

154 

Indexed 

2000 

POWORDR 

63 

Indexed 

700 

POVJCHECK 

63 

Indexed 

1300 

POWBANK 

1  1  1 

Indexed 

20 

POWBNKAC 

12 

40 

POWSHIPN 

72 

Indexed 

2000 

TOTAL 

1263 

12530 
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4 .   Using  the  Database 

The   database   can  be  used  for  all  the  POWCP  by  using 
the  Tabletalk  utility. 

a.  RFP  process 

(1)  Routine  //  1.  The  routine  is  generated  to  match 
the  data  classes  of  any  particular  RFP  with  the  data  classes 
of  all  vendors.  The  result  is  a  vendor  list  for  all  vendors 
that  matches  the  data  classes  of  the  RFP. 

(2)  Routine  //  2.  This  routine  generates  an 
RFP/Proposal s  list  which  summarize  the  RFP  process  and  shows 
all  proposals  received  from  all  vendors.  This  list  is  send 
along  with  the  physical  proposals  to  AA. 

(3)  Routine  //  3.  This  is  a  general  purpose  routine 
which  produces  a  list  of  the  basic  data  in  each  database 
file.  This  routine  can  be  enhanced  to  produce  a  variety  of 
lists  which  suit  certain  logical  conditions  such  as  a  list 
of  all  vendors  with  specific  data  classes.  Of  course  we  have 
to  join  the  vendor  data  class  file  with  the  vendor  file 
before  we  can  generate  the  reports. 

b.  Administer  Open  Contacts  Function 

(4)  Routine  it  4 .  Produce  a  list  of  all  invoices 
paid  to  a  particular  contract  with  its  values  and  paid 
dates.  The  join  between  the  contract  file  and  the  invoices 
file  must  be  done  before  we  use  the  Tabletalk.  The  same 
routine  is  generated  by  the  Tabletalk.  Similar  routines  can 
be  generated  for  the  pay  order  and  the  shipment  notice. 
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(5)  Routine  //  5 .  Produce  a  list  of  all  checks  paid 
to  a  particular  vendor.  Joins  with  the  vendor  file  and  the 
checks  file  are  necessary  before  producing  the  report. 

(6)  Routine  if  6 .  Produce  a  Payment  Plan  for  all 
invoices  received  and  validated  to  be  paid  on  a  schedule 
according  to  the  due  dates  of  each  invoice.  This  list  allows 
the  financial  officer  to  manage  the  payment  in  the  most 
effective  way  and  prevent  missing  payment  of  any  invoice. 

(7)  Routine  //  7.  Produce  the  financial  status 
about  all  active  contracts  which  shows  the  contracts  against 
the  amount  of  money  paid  for  each  one.  This  report  is  very 
important  for  the  cash  flow  management  of  the  fund  dedicated 
for  the  contracts. 

(8)  Routine  it  8 .  A  validation  list  of  all  check 
values  and  dates  issued  to  a  particular  bank.  This  list  can 
be  used  to  check  the  balance  sheet  of  the  bank.  This  routine 
can  be  adapted  to  produce  reports  to  monitor  payment  from 
loans  . 

(9)  Routine  #  9.  Produce  a  status  list  of  each 
contract  from  the  point  of  view  of  the  shipment  and  compare 
these  reports  with  the  contract  terms.  The  importance  of 
this  report  comes  from  its  ability  to  measure  vendor 
performance  and  address  any  delay  from  the  schedule  to 
allow  the  contracting  officer  to  take  the  necessary  action 
in  suitable  time. 


(10)  Routine  #  10.  Produce  a  list  of  the  received 
shipment  notices  to  compare  it  with  the  reports  received 
from  the  Freight  Forwarder  to  check  the  performance  of  FF. 

(11)  Rout  ine  tf  11.  Produce  list  of  officers  under 
training  for  each  contracts  with  information  about  the 
training  period. 

(12)  Routine  //  12.  Produce  mailing  list  each  month  to 
send  the  monthly  salary.  This  list  takes  much  time  in  the 
manual  system. 

(13)  Routine  tf  13.  Produce  a  list  of  training  schedule 
dates  to  inform  AA  ahead  of  time  to  prepare  and  send 
training  officers. 

(14)  Routine  It  14.  A  list  is  produced  of  all  the 
Guarantee  letters  whose  validity  date  is  close  to  the  end  of 
the  validity  period,  sorted  by  date  so  the  renewal  can  be 
done  in  a  suitable  amount  of  time.  This  list  is  produced  as 
required  to  assist  the  Financial  officer  in  following  the 
guarantee  letters. 

5.   Designed  Software 

The  POW  software  is  designed  as  a  menu  driven  by  the 
user.  The  POW  main  menu  screen  is  appear  when  issue  the  name 
of  the  main  module  (EX  POWMAI NM . FEX )  .  Selecting  the  options 
from  the  screen,  each  menu  leads  the  user  to  another  one.  A 
help  facility  is  provided  to  let  users  move  from  one  screen 
to  another.  Three  utilities  we  are  going  to  use  are  the 
Filetalk   which   allow  describing  the  Master  Data  File  (MDF), 
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the  Automode  which  allow  loading  the  database,  and  the 
Tabletalk  which  allow  producing  different  reports.  Describ- 
ing MDF  is  already  done  by  the  author  after  determining  the 
software  requirements  of  POWCP,  a  meaningful  names  is  select- 
ed to  allow  easy  understanding  for  the  user.  The  following 
pages  illustrate  a  navigation  through  the  designed  system: 
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Screen  //  1,Main  Menu 

WELCOME  TO 
POW  DECISION  SUPPORT  SYSTEM 
MAIN  MENU 
DATA  ENTRY  /  UPDATE  /  DELETE  ....  1 

CREATE  NEW  FILE  DESCRIPTION  2 

GENERATE  REPORTS  3 

EXIT  4 

HELP  5 

SELECT  (12  3  4  5) 

Select  Option  1 

WELCOME  TO  THE  PC/FOCUS 
AUTOMATIC  DATA  MANAGEMENT  SYSTEM 

PLEASE  ENTER  THE  NAME  OF  THE  FILE 
YOU  DESIRE  TO  MODIFY: 
File  name  — >  POWDEP 

Screen  //  2, Main  Edit 

AUTOMATIC  DA-TA  MANAGEMENT  FILE   POWDEP 
PLEASE  SELECT  A  PROCESS 

1  ADD  NEW  RECORDS 

2  ADD  NEW  RECORDS,  UPDATE  EXISTING  RECORDS 

3  UPDATE  EXISTING  RECORDS  ONLY 

4  DELETE  RECORDS 

5  RETURN  TO  MAIN  MENU 

ENTER  YOUR  SELECTION  (12  3  4) 

Select  Option  1 

AUTOMOD  OPTION  //1...ADD  NEW  RECORDS 

•TAB'  FOR  NEXT  FIELD  'ENTER'  TO  TRANSMIT  DATA 

'F7'   FOR  PRIOR  SCREEN  ' F8 '      FOR  NEXT  SCREEN 

'F3'   TO  RETURN  TO  PREVIOUS  MENU 

DEPART  ID   : 
DEPART  NAME: 
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Enter  Data 


DEPART  ID   :  02 

DEPART  NAME:  ARMAMENT  AUTHORITY 

Response  — >...  RECORD  ACCEPTED  ENTER  NEXT  RECORD 


Enter  the  same  data  to  check  validation  facility 

DEPART  ID   :  02 

DEPART  NAME:  ARMAMENT  AUTHORITY 


Response  — >...  RECORD  ALREADY  EXISTS  REJECTED 


Select  option  2  in  Edit  Screen 

AUTOMOD  OPTION  // 2  .  .  .  ADD/ U  P  D  ATE  RECORDS 

'TAB'  FOR  NEXT  FIELD  'ENTER'  TO  TRANSMIT  DATA 

•F7'   FOR  PRIOR  SCREEN  ' F3 '     FOR  NEXT  SCREEN 

•Fj'   TO  RETURN  TO  PREVIOUS  MENU 


DEPART  ID   : 
DEPART  NAME: 


DEPRESS  ENTER 


Enter  key  (02) 

DEPART  ID   :  02 

DEPRESS  ENTER 

DEPART  NAME:  ARMAMENT  AUTHORITY 

FOCUS  response   — >  UPDATING  EXISTING  RECORD 


Enter  new  Department   (03) 


DEPART  ID   :  Oj 

DEPART  NAME:  TANK 

Acknowledge  — >    ADDING  NEW  RECORD 


DEPRESS  ENTER 
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Select  option  3  in  Edit  Screen 

AUTOMOD  OPTION  //3..  .UPDATE  EXISTING  RECORDS 

'TAB'  FOR  NEXT  FIELD  'ENTER'  TO  TRANSMIT  DATA 

'F7'   FOR  PRIOR  SCREEN  ' F3 '     FOR  NEXT  SCREEN 

'F3'   TO  RETURN  TO  PREVIOUS  MENU 


DEPART  ID   :  03 
DEPART  NAME:  TANK 


DEPRESS  ENTER 


ENTER  NEW  VALUES 


Enter  new  record 


DEPRESS  ENTER 


DEPART  ID   :  04 

DEPART  NAME: 

Acknowledge  — >   RECORD  DOES  NOT  EXIST ....  ENTER  NEXT  RECORD 


Select  Option  3  in  Edit  Screen 

AUTOMOD  OPTION  //M.  ..DELETE  EXISTING  RECORDS 

'TAB'  FOR  NEXT  FIELD  'ENTER'  TO  TRANSMIT  DATA 

'F7'   FOR  PRIOR  SCREEN  'F8'     FOR  NEXT  SCREEN 

'F3'   TO  RETURN  TO  PREVIOUS  MENU 


DEPART  ID 


02 


Acknowledge . : 


RECORD  DELETED 


"The  following  are  the  basic  screen  of  POWCP  system. 
Notice  that  we  select  the  add/update  option  and  dropped  the 
help  part  of  each  screen  to  save  space. 


135 


Screen  it    3,    Vendor  Data 


VENDOR  ID 


THOMAS-VOL-N 
VENDOR  NAME: 
POF  CONTACT: 
VENDOR  ADRES 


VENDOR 
VENDOR 
VENDOR 
VENDOR 


CITY: 
ZIPC: 
TELEX 
START 


DEPRESS  ENTER 


THOMAS  PAG  N 


VENDOR  STATE: 

VENDOR  PHONE: 

VENDOR  ASSET 


Screen  //  4,  Item  class 


VENDOR  IDl 
VNDR  ITEM  C 


DEPRESS  ENTER 


Screen  //  5,  Vendor  /  Department 


VENDOR  ID2  : 
VNDR  DEP  NO: 


Screen  //  6,RFP  Data 


RFP  NO 


RFP  DATE    : 
RFP  SUBJECT: 
n'  of  VENDORS: 
RFP  COMMENTS: 


DEPRESS  ENTER 
DEP  ID 


NOF  PROPOSAL 


Screen  it    7,  RFC  Data 


I 


RFC  NO 


RFCDATE    : 
DEPART  NO! 
RFC  SUBJECT 
FUND  LETTER 
FUND  AMMOUNT: 
RFC  COMMENT: 


DEPRESS  ENTER  

RFP  N01 
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Screen  //  8, Contract  Data 


CONTRACT  NO: 


DEPRESS  ENTER 


CONTRACT  NAM 
CONTRACT  DE3 
CONTRACT  DEP 
CONTRACT  DAT 
CONT  COMM   : 


CONTRACT  VID 
CONT  VALUE  : 


Screen  //  9, Contract  Item 


CONTRACT  NOl  : 
CONT  ITEM   : 


Screen  //  10,  Invoice 


INVOICE  NO 


DEPRESS  ENTER 


INV  CONT  NO: 
INVOICE  SUBJ 
INV"  VENDR  ID 
INVOICE  VALU 
INV  CHECK  NO 
INV  COMM    : 


INVOICE  DATE 
INV  DUE  DATE 
INV  PAY  DATE 


Screen  //  11,  Pay  order 

PAY  ORDER  NO: 


DEPRESS  ENTER 


PAY  ORDR  DAT: 

PAY  ORD  BANK: 

PAY  0  VID   : 

PAY  TO  WHOM  : 


PAY  0  INV  NO 
PAY  0  VALUE: 


Screen  //  12,  Pay  Check 


CHECK  NO 


CHK  PAY  DATE: 
CHK  BANK    : 
CHK  VENDR  ID: 
CHK  TO  WHOME: 


DEPRESS  ENTER   

CHK  INV  NO 
CHK  VALUE 
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Screen 


13,  Bank  Data 


BANK  NO 


DEPRESS  ENTER 


BANK  NAME 

BANK  ADDRES 

BANK  CITY 

BANK  STATE 

BANK  PHONE 


BANK  ZIPC 
BANK  TELEX 


Screen  it     14,  Bank  Account 


BANK  N01 
BANK  ACC  NO 


DEPRESS  ENTER 


Screen  //  15,  Shipment  Notice 

SHIP  NOTICE; 


DEPRESS  ENTER 


SHIP  CONT  NO: 
SHIP  SUBJECT: 
S  H  LP  I N  V  NO: 


SHIP  DATE 
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VI.  CONCLUSIONS  AND  RECOMMENDATIONS 


A.   CONCLUSIONS: 

1.  The  POW  system  as  presented  in  this  thesis  is  not 
exactly  the  same  as  the  existing  POW  system  because  of  time 
and  travel  constraints,  however,  the  main  functions, 
problems  and  opportunities  of  POW  have  been  addressed. 
Adaptation  of  the  system  to  POW  or  any  other  Procurement 
Office  will  need  only  minor  effort  compared  to  the  effort 
spent  in  developing  this  system.  Fortunately  PC/FOCUS  with 
its  Fourth  Generation  Language  and  facilities  will  allow 
easy  adaptation  of  the  system. 

2.  No  system,  no  matter  how  efficient  it  is,  will  be 
effective  if  it  is  not  employed  by  its  users.  There  is  the 
possibility  that  the  proposed  system  will  not  be  used  any 
more  effectively  than  the  present  manual  system.  However,  it 
is  felt  that  the  probability  of  this  happening  will  decrease 
as  the  users  realize  the  benefits  of  the  system.  During  the 
analysis  phase  all  users  of  the  system  showed  willingness  to 
participate  in  using  a  computer  system  which  would  improve 
the  effectiveness  of  the  system.  The  manual  system  has  no 
more  capability  to  deal  with  the  increased  demand  for 
procurement  activities  in  the  USA  market.  Of  course,  it  is 
the  responsibility  of  POW  to  support  and  require  use  of  the 
system  once  it  has  been  proven  effective. 
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3.  The  approach  used  to  design  the  system  is  the 
Iterative  Design  Approach  or  Staged  Development  Approach. 
The  present  design  of  POWCP  system  is  the  first  iteration, 
the  Commercial  Procurement  function.  After  receiving  user 
feedback  from  the  initial  system,  the  second  iteration  will 
start.  This  system  will  be  expanded  into  a  general  purpose 
Decision  Support  Systems  (DSS)  to  be  used  in  the  procurement 
activities  of  foreign  country  procurement  offices.  Such  a 
system  with  the  DSS  generator  'database'  will  provide  an 
excellent  decisionmaking  tool  as  well  as  providing  support 
for.,  routine  operation  of  the  Management  Information  System, 
for  example  financial  management  and  tracking  of  contracts. 

4.  Implementing  the  systein  required  extensive  efforts  , 
especially  in  building  the  database  which  is  the  foundation 
for  any  other  improvements  to  the  system.  The  most  difficult 
problem  to  overcome  is  the  data  entry  phase  for  initial 
loading  of  the  database.  The  willingness  and  support  of  the 
POW  Director  and  specialized  officers  are  essential  for  the 
success  of  this  system. 

5.  The  use  of  PC/FOCUS  provides  fully  compatibilty 
with  the  mainframe  FOCUS  and  its  capability  to  handle 
external  files  (not  produced  by  FOCUS)  will  give  the  system 
flexibility  to  interface  with  other  systems. 

6.  As  long  as  increases  in  microcomputer  technology 
continue,  no  limits  are  foreseen  for  the  system  capability, 
including  multi-user  and  wide  area  communication  with  Cairo. 
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B.   RECOMMENDATIONS: 

The  objectives  of  the  thesis  nave  been  successfully 
completed.  Learning  about  computer  systems  development 
methodology  without  application  is  like  taking  swimming 
lessons  without  actually  swimming.  The  process  of  developing 
POW  was  a  real  challenge.  The  following  remarks  about  the 
system  can  be  made: 

1.  At  the  beginning,  the  actual  size  of  the  system 
effort  was  underestimated  which  is  a  common  a  pitfall  in 
system  development. 

..-  2.  Walking  through  the  details  of  the  system  using  the 
structured  systems  analysis  technique  enforced  the  developer 
to  address  and  describe  more  details  about  the  system  which 
spent  more  time  and  efforts  than  required  within  the  time 
limitation  of  doing  the  thesis.  However  this  technique  ha-s 
been  proven  succeeded  in  designing  a  roubist  information 
systems  in  the  real  world  situation. 

3.  Combining  building  the  DSS  generator  with  the 
iterative  design  approach  of  DSS  leads  to  a  conflict  in 
developing  system  requirements.  The  DSS  generator  needs  a 
detailed  and  complete  systems  analysis  to  build  the  data 
dictionary  down  to  the  primitive  level  of  detail.  (Data 
elements  that  cannot  be  divided  any  more  and  processes  that 
cannot  be  exploded  any  more.)  On  the  other  hand,  the 
iterative  design  approach  requires  building  DSS  with  short, 
rapid   feedback   from   users   to   ensure   that  development  is 
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proceeding  correctly.  This  may  be  very  difficult  if  we  start 
from  a  manual  system  like  POW.  To  solve  this  conflict  in  the 
real  world  probelms,  developing  the  DSS  (either  the 
iterative  or  the  complete  DSS)  should  be  started  from  a 
database  foundation. 

4.  Using  software  development  tools  is  very  important, 
especially  in  building  the  DFD  and  the  system  data 
dictionary. 

5.  Importance  of  documentation  is  addressed  during  the 
systems  development.  Self  documentation  and  giving  data 
elements  meaningful  names  are  very  important  in  designing 
the  system . 

6.  Deep  understanding  of  the  system  is  hard  to  obtain 
unless  you  walk  through  the  system.  The  DFD  gives  the 
developer  the  opportunity  for  self  feedback  and  to  readjust 
the  system  as  necessary. 

7.  This  thesis  can  be  used  as  a  requirements  document 
for  any  future  development  of  a  DSS  for  the  Egyptian  Armed 
Forces  . 

Based  on  the  learning  experience  dicussed  above,  the 
following  recommendations  can  be  made  for  the  future 
enhancements  of  the  POW  system: 

1.  It  is  strongly  recommended  that  efforts  continue 
on  designing  a  usable  DSS  for  POW.  The  cost-benefits 
of  using  the  system  is  extremely  favorable. 

2.  Utilization  of  PC/FOCUS  and  its  utilities  associated 
with  the  structured  system  analysis  technique  are 
most  suitable  for  the  iterative  design  approach  we 
used.  The  recommendation  is  to  purchase  the  software 
for  implementing  and  using  the  system. 
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j.   The   most   suitable   hardware   for   implementing   the 
system  are; 

a.  IBM-XT  or  IBM-AT  microcomputer  (IBM-AT  is 
preferable  because  its  faster  than  IBM-XT)  with 
640  KB  and  at  least  one  floppy  diskette  derive 

b.  Hard  Disk 

c.  IBM  Enhanced  Graphic  Adapter  to  allow  using 
Arabic  Language  facilities  in  PC/FOCUS. 

d.  Color  Monitor  '. 

e.  Matrix  Printer 

f.  Power  Supply  and  Accessories 
4 .   Future  Recommendation 

It  is  recommended  to  advance  the  implementation  of 
the  proposed  system  until  the  third  iteration,  at  least.  The 
first  and  second'  iterations  will  emphasize  building  the  DSS 
generator  and  giving  acceptance  by  POW  users.  The  third 
iteration  will  use  the  PC/FOCUS  capability  to  build  other 
two  modules  of  the  DSS:  a  model  management  subsystem  which 
allows  analytic  capabilities  to  be  added  to  the  system  like 
evaluation  of  alternatives  and  formulating  relationships 
between  variables  in  a  way  that  permits  the  creation  of 
simulation  or  "what  if"  models,  and  a  dialog  management 
component  which  can  be  tailored  to  POW  functions  with  a 
complete  help  facility  to  give  users  of  the  system  full 
capabilities  without  prior  knowledge  in  computer 
programming.  PC/FOCUS  has  the  facilities  to  build  both 
components . 
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APPENDIX  A 


DFD  CONVENTIONS 


Structured  Systems  Analysis  (SSA),  as  presented  in  the 
reference  "  Structured  Systems  Tools  and  Techniques"  by  Gane 
and  Sarson  [Ref.  3]  is  a  technique  used  to  perform  systems 
specification.  Data  Flow  Diagrams  (DFD)  are  used  to  picture 
the  system  and  the  Data  Dictionary  is  used  t:o  define  the 
data  elements  and  the  data  structure.  Processing  logic  pres- 
entations, such  as  decision  tables  and  structured  English 
are  used  to  precisely  specify  processing  sequences  in  terms 
that  are  understandable  to  the  user  and  developer.  For  the 
commercial  procurement  subsystem,  the  SSA  specification  is 
refined  to  the  detailed  design  level.  For  the  other  sub- 
system we  stop  at  the  software  requirement  specification. 
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A.   DFD  SYMBOL  CONVENTIONS 

The  logical  Data  Flow  Diagrams  are  very  important  for 
picturing  the  system  to  the  user;  they  provide  a  blue  print 
of  the  system.  This  way  of  presenting  the  system  provides  a 
communication  tool  between  the  systems  analyst  and  the  user  J 
on  one  side,  and  between  the  systems  analyst  and  the  soft- 
ware programmers  on  the  other  side.  The  DFD  is  designed  to 
present  the  processes  in  a  logical,  top  down  approach, 
independent  of  physical  location  or  physical  implementation. 
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This   technique   emphasizes   the  data  flow  through  the  system 

providing   a   comprehensive   understanding  of  the  system  and 

resulting   in  the  Data  Dictionary  the  most  valuable  output  in 

systems  development. 

As   an  example,  consider  the  following  simple  function  in 

DFD: 

The   system  will  receive  purchase  orders  from  customers, 

check   the'm   against   a   file   of  items  available,  check 

against   some   file   to   see  that  the  customer  credit  is 

okay,  and  cause  the  items  ordered  to  be  sent  out  with  an 
invoice  . 

We  could  show  this  logical  DFD  as  follows: 


BOOK  DATA 


Orders 

f                            y 

OUST. 

Rounded 
rectangle 

^ 

Invoices 

credit 
status 


CUSTOMER  DATA 


Figure  1  Logical  Data  Flow  Diagram  (DFD) 


Only  four'  symbols  are  used  to  picture  this  simple 
function.  The  flow  of  data  may  physically  be  contained  in  a 
letter  or    an   invoice,  in  a  telephone  call,  from  program  to 
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program,  via  satellite  datalink  or  anyplace,  where  data  flow 
from  one  entity  or  process  to  anther.  a  process  may 
physically  be  a  room  full  of  operators  receiving  mail 
orders,  getting  money  from  an  ATM  machine,  or  a  combination 
of  manual  and  automated  activities.  A  data  store  can  be  a 
rotary  card  file,  a  record  book,  a  microfiche,  a  filing 
cabinet,  even  a  table  in  core,  or  magnetic  file  on  tape  or 
disk.  Using  the  four  symbols  enable  us  to  draw  a  picture  of 
system  without  committing  ourselves  to  how  it  will  be 
implemented.  We  started  with  a  very  general  DFD  and  then  we 
could  go  to  the  details  step  by  step.  Figure  2.2  shows  the 
expansion  of  the  previous  DFD.  [Ref.  3] 


^ 

i 

Credit 
Status 

CUST0nER3 

PUBLISMEUS 


Publisher 
«7  Data 


VL 


Ass  i  rn  b  1  e 
requistions 


to  publisher     Orders 


V 


Purchase 


pubiinhef 


orders 
batched 


PENDING  ORDERS 


Figure  2   Expanded  Logical  DFD 

We  continue  the  expansion  of  DFD  in  a  top  down  fashion 
until   we   get  to  the  elementary  process  level,  that  can't  be 
divided  any  more . 

Tracing  the  DFD  is  very  important  to  understanding  the 
system.  It  is  advisable  for  the  systems  analyst  to  present  a 
walk  -through  of  the  DFD  with  users  at  the  beginning,  so  the 
user   can  get   the   concept   of  DFD.   The  preferable   way  to 


1  46 


walkthrough  the  DFD  is  to  start  from  the  external  entities 
and  describe  the  input  data  flow  lines  and  each  process  in  a 
logical  sequence,  and  then  follow  the  output  data  flow  lines 
until  exits  or  is  stored  somewhere  in  the  DFD. 

B.    SYMBOLS  DESCRIPTION 

1 .   External  entities 

The  most  usually  logical  classes  of  things  or 
people  which  represent  a  source  or  destination  of 
transactions,  e.g,  vendors,  officers,  tactical  units. 
Armament  Authority,  or  Department.  If  our  system  accepts 
data  from  another  system  or  provides  data  to  it,  that  other 
system  is  an  an  external  entity. 


ExtemaJ  Entity 


Figure  j   External  Entity 


An   entity  is  identified  by  lower  case  letters  in  the  upper 
left  hand  corner  for  reference. 
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2.   Data  flow 

Data   flow   is   symbolized  by   an  arrow,  figure  2.4. 

Each   data   flow   may   be   thought  of   as   a  pipe  down  which 

parcels   of  data  are  sent.  The  data  flow  may  be  referenced  by 

giving   the   processes,   entities,  or  data  store  at  its  head 
and  tail. 


n 


rroi 


(Dala  Flov) 


Figure  4   Data  flow  symbols 

3 .   Process 

The  process  can  be  symbolized  by  an  upright 
rectangle,  with  the  corner  rounded,  optionally  divided  into 
three  areas,  Figure  2.5. 


identification  of  the  Processes 


■f^ 


Description  of  the  function 


■!► 


Physical  Location  where 
Performed 


^ 


1 .  Routinq 


Route 

the 

Proposal; 


POW 


Figure  5   Process 
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4 .   Data  store 

Data  store  can  be  symbolized  by  a  pair  of  horizontal 
parallel  lines,  closed  at  one  end  (Figure  2.5).  Each  store 
can  be  identified  by  a  "D"  and  an  arbitrary  number  n  in  a 
box  at  the  left  end  for  easy  reference. 


j      Open  ended  rectangle 


Figure  6   Data  store 


The  external  entities  and  the  data  stores  may  be 
duplicated  to  prevent  interconnections  between  aata  flow 
lines  (Figure  2.7).  In  the  external  entity,  multiple  diag- 
onal lines  are  used  to  indicate  that  the  external  entity  is 
pictured  more  than  once  in  the  same  DFD. 


Occurs  one  time 


Occurs  tvo 
times 


Occurs  three 

— r • 

times 


Figure  7.   Duplication  of  the  External  entity 
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In  the  data  store,  multiple  vertical  lines  are  used 
to  indicate  that  the  data  store  is  pictured  more. than  once 
in  the  same  DFD,  Figure  2.8. 


Occurs  one  time 


Occures  tvo  times 


Occurs  three  times 


Figure  8,   Duplication  of  Data  Store 

The  information  presented  , so  far  is  sufficient  to 
understand  ohe  DFD.  The  second  step  is  to  put  detailed 
information  about  the  DFD  in  a  Data  Dictionary. 

C.    THE  DATA  DICTIONARY 

The  data  dictionary  keeps  all  the  details  and  contents 
about  the  data  flows,  data  stores,  and  processes.  The 
information  we  need  to  keep  in  the  data  dictionary  is 
classified  into  three  levels: 
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1 .  Data  Elements 

These  are  the  pieces  of  data  that  it  is  not  meaning- 
ful to  decompose  further  for  the  applicated  at  hand;  e.g, 
date,  product  number,  etc. 

2 .  Data  Structures 

These   are  made  up  of  data  elements,  or  of  other  data 
structure,  or  a  mixture  of  both,  for  example: 
VENDOR 

VENDOR-ID 
VENDOR-NAME 
FIRST-NAME 
LAST-NAME 
PHONE 

AREA-CODE 
NUMBER 
EXTENSION 
BUSINESS-START-DATE 
BUSINESS-ASSET- VALUE 
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3 .   Data  Flow  and  Data  Stores 

■  Data  flows  are  paths  or  "pipelines"  along  which  data 
structures  travel.  Data  stores  are  places  where  data  struct- 
ures are  stored  until  needed.  In  other  words,  data  flows  are 
data  structures  in  motion,  data  stores  are  data  structure  at 
r est . 

The   data   description   hierarchy   can   be  represented  as 
follows.  II 


I 


Data  Element 


Figure  9  Data  description  hierarchy 
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APPENDIX    B 
MODULES     LISTINGS 


A.     POWMAINM: 


SET    PA 

SET    MS 

-TOP 

LET     !  1 

-CRTCL 

-BEGIN 

-SET    & 

-TYPE 

-CRTFO 
_  If 

_  II 

_  II 

_  II 

_  II 

_  It 

_  It 

_  II 

_  II 

_  M 
_  tl 
_  II 
_  II 
_  It 
_  II 
_  II 
_  II 
_  II 
_  M 
_  tl 


USE    =    OFF 
G  =  ON 

=  HELP 
EAR 

REPLAYrO; 

RM 


WELCOME    TO 
POW    DECISION     SUPPORT    SYSTEM 

MAIN     MENU 


DATA    ENTRY    /     UPDATE    /     DELETE     ....  1 

CREATE     NEW    FILE     DESCRIPTION     2 

GENERATE    REPORTS     J 

EXIT     4 

HELP     5 


SELECT     (12    3    4    5)     <&REPLAY    <77 


&REPLAY  EQ  2 

&REPLAY  EQ  3 

&REPLAY  EQ  4 

&REPLAY  EQ  5 


-IF    &REPLAY       EQ        1     GOTO    AUTO 

ELSE     IF 

ELSE    IF 

ELSE    IF 

ELSE    IF 
-AUTO 

EX    POWAUTO 
-RUN 

-CRTCLEAR 
-GOTO     BEGIN 
-FTALK 

FILE     TALK 
-RUN 


GOTO  FTALK 

GOTO  TTALK 

GOTO  EXIT 

GOTO  HELP     ELSE 


GOTO     NOPE 
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-CRTC 

-GOTO 

-TTAL 

TABLE 

-RUN 

-CRTC 

-GOTO 

-HELP 

EX  PO 

-RUN 

-CRTC 

-GOTO 

-NOPE 

-TYPE 

^  •  •  • 

-GOTO 
-qu  i  t 

-EXIT 


LEAR 

BEGIN 
K 

TALK 

LEAR 
BEGIN 

WHELP 

LEAR 
BEGIN 

&REPLAY  IS  NOT  A  VALID  OPTION 
PLEASE  REVIEW  OPTIONS  AND  RE-ENTER 
BEGIN 


B.   POWAUTO: 


-[Ref.   9] 


SET 

SET 

-TOP 

-CRT 

-IF 

-SET 

-GOT 

-NON 

-SET 

-STA 

-CRT 
_  II 

_  II 


PAUSErOFF 
MSGrOFF 

CLEAR 

&1. EXIST  EQ  0  GOTO  NONAME; 

&FNAME  =  &  1  ; 
0  GOTNAME 
AME 

&FNAME= • 
RT 
FORM 


WELCOME  TO  THE  PC/FOCUS 
AUTOMATIC  DATA  MANAGEMENT  SYSTEM 


t  . 
t 


■TYPE 
•TYPE 
■TYPE 


PLEASE  ENTER  THE  NAME  OF  THE  FILE 
YOU  DESIRE  TO  MODIFY: 
<T.&FNAME  <77   " 

PLEASE  WAIT 
THE  MAIN  MENU  IS  NOW  LOADING 
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-GOTNAME 

-IF  ^FNAME. LENGTH  GT  8 

-SET  &FF  =  iFNAME  1  I   ' 

-DOS  STATE  ^cFF 

-IF  &RETCODE  NE  0  GOTO 

NO  NAME; 

-SET  iREPLYr '   •  ; 

-SECTION  1 

-CRTFORM 

_  M 
^  II 


GOTO  BADNAME; 
MAS'   ; 


"  AUTOMATIC  DATA  MANAGEMENT  FILE  <D.<ScFNAME  <77   " 

, "  It 

•"  PLEASE  SELECT  A  PROCESS  " 


,  II 


II 

1 

II 

2 

II 

3 

II 

4 

II 

II 

5 

II 

II 

II 

II 

II 

ADD  NEW  RECORDS 

ADD  NEW  RECORDS,  UPDATE  EXISTING  RECORDS 

UPDATE  EXISTING  RECORDS  ONLY 

DELETE  RECORDS 

RETURN  TO  MAIN  MENU 


ENTER  YOUR  SELECTION  (1  2  j  4)  <&REPLY   <77 


II 


IF  &REPLY  EQ  1  GOTO  ADD  ELSE  IF  &REPLY  EQ  2  GOTO  ADDUP 
ELSE  IF  &REPLY 

EQ  3  GOTO  UP  ELSE  IF  &REPLY  EQ  U  GOTO  DEL  ELSE 

IF  &REPLY  EQ  5  GOTO  EXIT 

ELSE  GOTO  NOPE; 

ADD 

ODIFY  FILE  &FNAME 

RTFORM 

II 

AUTOMOD  OPTION  #1...ADD  NEW  RECORDS  " 

It 

'TAB'  FOR  NEXT  FIELD      'ENTER'  TO  TRANSMIT  DATA   " 

'F7'   FOR  PRIOR  SCREEN   'F8'   FOR  NEXT  SCREEN       " 

'F3'   TO  RETURN  TO  PREVIOUS  MENU  " 


CRTFORM 
« 

MATCH  » 

KEYS 

ON  NOMATCH  TYPE 


.  .  .  .  RECORD  ACCEPTED 
N  NOMATCH  INCLUDE 


ENTER  NEXT  RECORD 
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ON  MATCH  TYPE 

II   ri 

"....  RECORD  ALREADY  EXISTS  ....  REJECTED  ... 

LOG  DUPL  MSG 

OFF 

DATA 

END 

-TYPE  PLEASE  WAIT 

-TYPE 

-TYPE  PC/FOCUS  IS  LOADING  YOUR  FILE 

-RUN 

-TYPE  PLEASE  WAIT 

-TYPE 

-TYPE  PC/FOCUS  IS  UPDATING  YOUR  FILE 

-GOTO  SECTION! 

-ADDUP 

MODIFY  FILE  &FNAME 

CRTFORM 

"        AUTOMOD  OPTION  #2  .  .  .  ADD/ U P D ATE  RECORDS 
II 


It 


"    'TAB'  FOR  NEXT  FIELD   'ENTER'  TO  TRANSMIT  DATA  " 
"   'F7'   FOR  PRIOR  SCREEN    'F8'   FOR  NEXT  SCREEN  " 


Fj'   TO  RETURN  TO  PREVIOUS  MENU 


CRTFORM  * 

KEYS 
II   ' 

It  11 

MATC 
KEYS 
ON  M 


DEPRESS  ENTER 


H 


ON  N 
ON  M 
ON  M 

ON  N 

INCL 

LOG 

DATA 

END 

-TYP 

-TYP 

-TYP 

-RUN 

-TYP 

-TYP 

-TYP 

-GOT 

-UP 

MODI 


ATCH  TYPE  "UPDATING  EXISTING  RECORD  " 
OMATCH  TYPE  "ADDING  NEW  RECORD" 
ATCH/ NO MATCH   CRTFORM  T.»  NONKEYS 
ATCH  UPDATE 

OMATCH 

UDE 

NOMATCH  MSG  OFF 


PLEASE  WAIT 
PC/FOCUS  IS  LOADING  YOUR  FILE 
PLEASE  WAIT 


E 

E 

E      PC/FOCUS  IS  UPDATING  YOUR  FILE 

0  SECTIONl 

FY  FILE  &FNAME 
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CRTFORM 
It , 


"    AUTOMOD  OPTION  #3. ..UPDATE  EXISTING  RECORDS 
II , 


'TAB'  FOR  NEXT  FIELD  'ENTER'  TO  TRANSMIT  DATA 
'F7'   FOR  PRIOR  SCREEN  'F8'F0R  NEXT  SCREEN 
'Fj'   TO  RETURN  TO  PREVIOUS  MENU 


(I    M 

CRTFORM 

KEYS 
ti 

"  DEPRESS  ENTER 

MATCH  * 

KEYS 

ON  NOMATCH  TYPE 

"      RECORD  DOES  NOT  EXI ST . . . . ENTE R  NEXT  RECORD 

ON  MATCH  TYPE 

"  ENTER  NEW  VALUES  " 

It  It 

ON  MATCH  CRTFORM  T.» 

NONKEYS 

ON  MATCH  UPDATE 
» 

LOG  NOMATCH  MSG 
OFF 


DATA 

END 

-TYPE 

-TYPE 

-TYPE 

-RUN 

-TYPE 

-TYPE 

-TYPE 


PLEASE  WAIT 
PC/FOCUS  IS  LOADING  YOUR  FILE 
PLEASE  WAIT 
PC/FOCUS  IS  UPDATING  YOUR  FILE 


-GOTO  SECTION! 

-DEL 

MODIFY  FILE  &FNAME 

CRTFORM 
It 

"       AUTOMOD  OPTION  //4..  .DELETE  EXISTING  RECORDS 


'TAB' 
'F7  ' 


FOR  NEXT  FIELD      'ENTER'  TO  TRANSMIT  DATA   " 
FOR  PRIOR  SCREEN      'F8'     FOR  NEXT  SCREEN 

•F3'   TO  RETURN  TO  PREVIOUS  MENU  " 


CRTFORM  * 
KEYS 


MATCH 
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ENTER  NEXT  RECORD 


RECORD  DELETED 


KEYS 

ON  NOMATCH  TYPE 
tf  It 

"..  RECORD  DOES  NOT  EXIST 

ON  MATCH  TYPE 
It  It 

It 

ON  MATCH 

DELETE 

LOG  NOMATCH  MSG 

OFF 

DATA 

END 

-TYPE 

-TYPE 

-TYPE 

-RUN 

-TYPE 

-TYPE 

-TYPE 

-GOTO 

SECTION  1 

-BADNAME 

TYPE  INVALID  FILE  NAME  (EXCEEDS  8  CHARACTERS) 

-GOTO 

TOP 

-NOPE 

-TYPE  &REPLY  IS  NOT  A  VALID  OPTION 

-....PLEASE  REVIEW  OPTIONS  AND  RE-ENTER 

-GOTO  SECTI0N1 

-NONAME 

-TYPE  FILE  NAMED  &FNAMEI1.XXX  CANNOT  BE  LOCATED 

-PROMPT      &REPLY. RE-ENTER      FILE      NAME 

QUIT. 

-GOTO  SECTIONi 

-EXIT 


PLEASE  WAIT 
PC/FOCUS  IS  LOADING  YOUR  FILE 

PLEASE  WAIT 
PC/FOCUS  IS  UPDATING  YOUR  FILE 


OR 


TYPE 


C.   POWDIC: 

SET  PAUSE  =  OFF 
SET  MSG=OFF 
-TOP 

-CRTCLEAR 

-IF  &1. EXIST  EQ  0  GOTO  NONAME; 

-SET  &FNAME=&1; 

GOTO  GOTNAME 
-NONAME 

-SET  &FNAME= '  ' ; 

-START 

-TYPE  THIS  IS  THE  AN  ONLINE  HELP  SCREEN 
-CRTFORM 
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■PROMPT 
■END 


ONLINE     HELP     SCREEN  " 

---------  ti 

II 

INFORMATION  ON  FOCUS  <1>  " 

INFORMATION  ON  FOCEXECS  <2>  " 

DICTIONARY  MAINTENANCE   <3>  " 

QUIT  <U>: 

•I 

II 
If 

&SELECT.      WHAT  IS  YOUR  CHOIC  ? 


D.   POWHELP: 


RTCLEAR 

EGIN 

ET  &REPLAY=0; 

YPE 

RTFORM 


POW 

HELP  SCREEN 


1.  System  Description 

2.  Online  Help 
j  .  Exit 


SELECT  (12  3 


)  <&REPLAY  <77 


-IF  &REPLAY   EQ   1  GOTO  SYSDESC 

ELSE  IF  iREPLAY  EQ  2  GOTO 
ELSE  IF  ^REPLAY  EQ  3  GOTO 
ELSE  GOTO  NOPE; 

-ONLI 

EX  PO 

-RUN 

-CRTC 

-GOTO 

-SYSD 
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LSE  IF 
:LSE  IF 

LSE  GOTO 

NE 
IWDIC 

:LEAR 

BEGIN 
ESC 


ONLINE 
EXIT 


-TYPE 
•GOTO 
•NOPE 
•GOTO 
•qui  t 
•  EXIT 


***  WILL  BE  DEVELOPED  lATER   »»* 


BEGIN 


BEGIN 


160 


APPENDIX  C 
DATA  DICTIONARY 

The  following  are  the  list  of  DFD  Elements  in  the  Exist' 
ing  system  as  we  described  it  in  the  previous  DFD  (Commer' 
cial  Procurement): 


A.   EXTERNAL  ENTITIES 
NAMES 


ABBREVIATION   IDENTIFICATION 


Armament  Authority  AA 

Vendor  V 

Bank  B 

Defense  Security  Assistance 

Agency  DSAA 

Central  National  Bank  of 

Egypt  CNBOEG 

Fright  Forwarder  FF 

Independent  Market  Association     IMA 

United  State  Security  and 

Assistance  USASAC 
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B.  PROCESS: 

PROCESSES 


ABBREVIATION  IDENTIFICATION 


RFP  Function  RFPF 

Prepare  &  issue  the  RFP's  PIRFP 
Register  RFP  &  Rout  to 

Specialized  Officer  RRTSO 

Review  RFP  RRFP 

Select  Vendor  List  SVL 

Prepare  Copies  of  RFP  PCORFP 

Check  Vendor  Qualification  CVQ 

Add  New  Vendor  to  VL  ANV 
Receive  Proposals  From  Vendors     RPFV 
Register  Proposals  and  route 

to  the  Specialized  Officer  RPTSO 

Review  and  scan  Proposals  RASP 

Prepare  Summary  Reports  PSR 

Check  Vendor  Qualification  CVQ 

Send  Proposals  To  AA  SPTAA 

RFC  Function  RFCF 

Process  the  RFC  PRFC 

Rgister  &  Route  RAR 

Check  RFC  for  Completness  CRFC 

Determinr  the  Source  of  Fund  DSOF 
Prepare  the  contracting  and 

Implementation  Plan  PCIP 


1 

1  .  1 


1  .  1 

1  .2 

.  i 

.  4 

.5 

.  6 

1  .2 

1.2.1 
1.2.2 

1.2.3 
1.2.4 
l.J 
2 

2.  1 
2.1.1 
2.1.2 
2.  1  .  j 

2.1.4 
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Form  Negotiation  Team  FNT 

Negotiate  Vendors  VEGV 

Contract  Award  Process  CAWRD 

Prepare  Contract  Draft  PCD 

Calculate  Value  of  Contracts  CVC 

Check  the  Technical  Terms  CTT 

Collect  all  Documents  CAD 

Final  Review  of  the  Contracts  FROC 

Sign  the  Contract  STC 

Sign  The  Contract      •  SC 

Funding  Contracts  FC 

Identify  the  Source  of  Fund  ISOF 

Process  Fund  From  Budget  PFFB 

Collect  Documents  of  Contracts  CDOC 

Open  Credit  Letter  for  Vendor  OCRL 

Payment  of  Initial  Deposit  POID 

Process  Fund  From  Loan  PFFL 
Prepare  Request  for  Funding 

From  Loans  PRFL 
Payment  Initial  deposit  from 

Loan.  PIDFL 

Administer  Contract  AC 

Payment  Process  PAYP 
Register  and  Route  the  Payment 
Documents  to  the  Specialized 

Officer  RGR 

16J 


2.1.5 

2.2 

2.i 

2.3.1 

2.3.2 

2.3.3 

2.3.4 

2.3.5 

2.3.6 

2.4 

3 

3.  1 
3.2 

3.2.1 
3.2.2 
3.2.3 
3.  J 

J.  3.  2 

3.  J. 2 
4 

4.  1 


4.1.1 


Check  Payment  Documents 

Check  Duplication 

Check  Invoice  Amount 

Monitor  Training  of  Personnel 

Prepare  Training  Plan 

Inform  Vendor  by  Trainee  Names 

Prepare  Status  Reports 

Monitor  Shipment  of  Items 

Prepare  Shipment  Plan 

Compare    and  adjust  Shipment 

Reporting 

Prepare  Status  Reports 

Prepare  Progress  Reports 

Prepare  Comparison  Reports 

Prepare  Analysis  Reports 

Generate  Vendor  List 

Verify  vendors 

Check,  if  Vendor  Exist 


C.  DATA  STORES 
DATA  STORES 
Vendor  list  File 
RFP  Monitor  File 
Contracts  to  be  Funded 
Active  Contracts 


CPDOC 

U.  1  .2 

CHKD 

4.  l.i 

CHKIA 

4.1.4 

MTOP 

4.2 

PTP 

4.2.1 

IVBTN 

4.2.2 

PSR 

4.2.i 

MSOI 

4.  j 

PSHP 

4.3.1 

CADSH 

4.i.2 

REP  ' 

4  .  4 

PSREP 

4.4.1 

PPREP 

4.4.2 

PCREP 

4.4.  j 

PAREP 

4.4.4 

GVL 

5 

VERV 

5.  1 

CHKVE 

5.2 

ABBREVIATION   IDENTIFICATION 


VLF 

D1 

RFPMF 

D2 

CTBF 

Di 

AC 

D4 

I 


1 
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Contract  Monitor  File 

Pending  Proposals  File 

General  Log  Book 

Thomas  Register 

Pending  RFC  File 

Vendor  Meeting  Schedule 

Final  Reports  Collection  File 

Fund  Source  File 

Contracting  Implementation 

Plan 

Officers  Work  Load 

Rules  and  Regulations 

Best  and  Final  Offer 

All  Contract's  Document  File 

Budget  Monitor  File 

Loans  Monitor  File 

Previous  Payment  Monitor  File 

Training  Plan  File 

Sh  ipmen  t  Plan 

Shipment  Notice  Keeping  File 

Shipment  Monitor  File 

Pending  Vendor  Requests  File 


CMF 

D5 

PPF 

D6 

GLB 

D7 

TREG 

D8 

PRFCF 

D9 

VMS 

DIO 

FRCF 

Dl  1 

FSF 

D12 

CIP 

D13 

OWL 

D  14 

RAREG 

D15 

BAFO 

D16 

ACDOC 

D17 

BMF 

Dl  8 

LMF 

D19 

PPMF 

D20 

TPF 

D21 

SHPF 

D22 

SHNKF 

D2J 

SHMF 

D24 

PVRF 

D25 
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D.  DATA  FLOWS 
DATA  FLOWS 
RFP 


IDENTIFICATION 


RFP  Subject  &  date  received 

RFP  Subject  &  Department 
I  t 

New  Vendor  Name 

Proposals 

Vendor  list  with  RFP's 
I  t 

Proposals 


a-1 
a-1  .  1 

a-1  .1.1 

1.1.1-1.1.2 

1 .  1  .2-1  .  1  .  J 

1.1.3-1.1.4 

1  .  1 .4-b 

1.1.  1-D7 

1.2. 1-D6 

D2-1  .  1  .:s 

1  .  1  .2-D2 

1.1.3-1.1.5 

1-a 

1-b 

1  .  1-b 

b-1 

b-1  .2 

1  .2-Db 

D6-1  .  j 

1  .3-a 

b-1  .2.1 

1.2.1-1.2.2 

1.2.2-1.2.3 

D6-1 .2.3 


166 


I 


Proposals 

Number  of  Proposals  &  Vendors 
Vendor  data 


Vendor  Name 

RFP  Monitor  Data 
»  t 

Qualification  Form 

Replay 

Vendor  Company  Profile 

Qualified  Vendor  data 

New  Vendor  Data 

Supplementary  Vendor  List 

RFC 


Officer   Names 

Names  of  Negotiation  Team 

RFC  Subject  and  Date  Received 

Vendor  Telephone  &  Address 
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1.2.  j-a 
1.2.  3-D2 
Dl-1 
Dl-1  .  1 
Dl-1 . 1 . j 
Dl-1 . 1 . 4 
D6-1 .1.4 
1-D2 
1  .  1-D2 
1  .  1  .5-b 
b-1  .  1  .5 
D8-1  .1.5 
1.1.5-1.1.6 
1.1. 6-Dl 
1.1.6-1.1.4 
a-2 
a-2.  1 
2. 1-D9 
a-2.  1  .  1 
2.1.1-2.1.2 
2.  1  .2-2.  1  .3 
2.1.  3-2.  1  .  4 
D14-2. 1 . 5 
2.  1  .5-Dl  3 
2.1. 1-D7 
Dl-2  .  1 


Meeting  Schedules 

Appointment  Letter 

Vendor  Replay  to  the  App. 

New  Meeting  Schedule 

Final  and  Best  Offer  of  Vendor 

All  RFC  Documents 

Vendor  Selected 

Rules  and  Regulations 

RFP  Specifications 

Final  and  Best  Offer  Spec. 
Contract  Draft  1 
Fund  Letter 

Initial  Deposit  Value 
Total  Amount  Of  Contracts 
Contract  Draft2 
Contract  Draftj 
Notice  if  any 

Final  Documents  of  Contract 
Final  Draft  of  Contract 
Final  and  signed  Contracts 
Fund  Source  Information 
Copy  of  the  Final  Contracts 
Fund  Source 


2. 1-D10 
DlO-b 
b-2.  2 
2.2-D10 
D9-2.2 
2.2-Dl  1 
2.2-2. ^.  1 
D15-2.  3.  1 
D2-2.  j.  1 
D2-2. 3.i 
D16-2.  j.  :> 
2.3.1-2.3.2 
D12-2.  3.  2 
a-3.3. 1 
2. 3. 2-2.  5  .  U 
2.2. 3-2.  3.4 
2.3.2-2.  J.  J 
2.2. 3-2.  3.5 
2.3.3-2. J. 4 
2.5. 4-2. 3.5 
2.3.5-2. 3.6 
2.3. 6-a 
Dl 1-2. 3 
2.3.6-D17 
D12-2. 3 
D12-2. 1 .3 
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RFC  No  &  Date,  Time  of  Meeting 

Appointment  Leti:,er 

Final  Contract  Award  Reports 

Contracts 


Budget  status 

Certificates 
I  t 

Cont  racts  Data 
I  t 

Award  Letter 

Appointments 

Final  and  Best  offers 

Source  of  Fund 
t  I 

Source  from  Budget 
Credit  Letter 

Fund  Information 
Status  Data  about  Funding 
Payment  Data 
Request  to  open  an  ace. 
Payment  Order 
Payment  Order  For  Deposit 
Letter  To  Confirm  Payment  Order 
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2.1.  4-Dl  j 

2.1.  4-b 
2. 3-2.4 
2-a 
2.4-a 

3.  1-J.2.  1 

D18-3.2.  1 

b-3.2.  1 

a-3.1   ■ 

2.4-D5 

D5-3.2.2 

2.4-b 

2-b 

b-2 

a-3 

a-j.  1 

3.1-3.2   . 

e-3.2. 1 

3.2.  1-D2 
D2-3.2.2 
3.2.2-D13 
3  .2.  2-c 
3. 2. 2-b 
3.2.3-b 
3.2.3-c 


Agreement  Letter  From  Bank 
Amount  of  Initial  Deposit 
Justified  Sheet 
Signed  Contracts 
Funding  Request 
Initial  Deposit 
Contract  Information 
Guarantee  Letter 


Source  From  Loans 

Request  For  Funding  from  Loan 

Case  Designator 

Status  Information 
Letter  to  inform  Vendor 
Case  Information 

Open  an  Ace.  Request 

Credit  Data 
I  t 

Credit  and  Guarantee  letter 
Initial  deposit  payment  order 
Shipment  and  training  Notice 
Payment  Documents 


c-J.2.3 

3.2. j-D5 

a-3.3. 1 

a-3.3. 1 

3.3. 1-d 

3.3.2-b 

D17-3.3.2 

b-3.2 

b-j.2.  1 

b-3.3.2 

3  .  1-3  .  J 

3. 3-d 

d-j.  3 

d-3.3.2 

3.3.2-D5 

3.3-b 

3.3-D2 

J.3-D19 

3.2-G 

3. 2-D2 

3.2-D18 

3-c 

3-b 

b-4 

b-4 

b-4  .1.1 


1  70 


Payment  document 


Previous  Payment 
f  t 

Invoice  &  Amount 

Reasons  for  Non-Payment 

Approved  Payment  Document 

Invoice  Paid 

Checks 

Payments  (checks  &  orders) 
t  t 

Payment  Information 
Training  Schedule 


Training  Information 


Names  of  Trainees 


Training  progress  Reports 

Shipment  and  training  notice 
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4.1.1-4.1.2 
4.1.  2-4 .  1  . J 
4.  1  .3-4.  1  .4 
D5-4. 1 .3 
b-4  .  1 

4.1.  4-D5 
4.1. 4-b 
4.1. 4-4  .1.5 
D20-4  .1.4 
4. 1 .5-b 

4-c 
4  .  1-c 
4. 1-D5 
b-4. 2 
4.2-a 
b-4. 2. 1 
4 . 2-D5 
D5-4 .2.1 
4.2. 1-D21 
4.2.2-a 
4.2. 2-D2  1 
4.2.2-D5 
4 .2. 2-b 
b-4  .2.3 

4.2.  3-a 
4-a 


Shipment  Notice 


Shipment  Information 


Items  &  quan.tity  to  be  Shipped 

Shipment  Schedule  and  priority 

Shipment  Progress  Reports 

Priority  of  Shipping 

Total  Values  of  item  Shipped 

Contra ct  Monitor  Information 

Reports 

Status  Information 

Progress  Information 

Comparison  Information 

Analysis  Information 

Vendors  Requests 

Acknowledge  to  vendor 
Qualification  Form 
Qualification  Form  Filled 
New  Vendor  Recommended  From  AA 
Accepted  Vendor  Data 
Enquiry  For  Business  Status 
Suggested  Vendor  list  from  AA 
Company  Profile 
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4.  3-a 

f-4.i 
4.3-D5 

4.  J.2-D24 
D2i-4.3.2 
D5-4  .  J  .  1 

U . 3 . 1-D22 
f-4  .J. 2 
D22-4.  3.2 
4. J.2-D5 
D5-4. 4 
4  .  4-a 
D5-4 .4.1 
D5-4  .4.2 
D5-4. 4.3 
D5-4 .4.4 
b-5 
b-5  .  1 
5-b 

5.  1-b 
b-5.  1 
5.2-5.1 
5.  1-D1 
i-5.  1 
a-5.2 
D8-5 .2 


New  Vendor  Data 

Existing  Vendors  data 

List  of  Vendors  Who  are  to  USA 


5-D1 

5.2-1 

J-5.2 


17:i 
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